Open Metering System  
Specification  
Volume 2  
Primary Communication  
Issue 5.0.1 / 2023-12  
RELEASE  
© Open Metering System Group e.V., 2023  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Document History  
Version Date  
Comment  
Editor  
1.0.0  
1.0.1  
1.0.2  
2008-06-27 First final Version  
2008-07-01 Editorial Revision  
U. Pahl  
U. Pahl  
H. Baden  
2008-07-21 Some format adoptions; table index added; content  
index limited to structure level 3.  
1.0.3  
2009-02-25 Correct mistake in Table 10  
Add changes for 2nd Version  
U. Pahl  
1.0.4  
1.0.5  
1.0.6  
1.0.7  
1.0.8  
2009-05-13 Revision in AG1  
AG1  
2009-05-30 Add changes for 2nd Version  
2009-06-11 Update Annex  
U. Pahl  
U. Pahl  
U. Pahl  
U. Pahl  
2009-06-30 Changes based on protocol#23  
2009-07-03 Last changes of online review; update Annex A;,L and  
M, editorial review  
1.0.8  
1.0.9  
2009-07-05 Editorial and formal review  
H. Baden  
2009-07-17 Add Time sync frame to MUC-Status, separate ACC-No U. Pahl  
for wired M-Bus and wireless M-Bus  
2.0.0  
2.0.1  
2009-07-20 Release as V2.0.0  
U. Pahl  
U. Pahl  
2010-04-10 Add Changes for 3rd Version, Add sync Meter  
transmission; New CI-Fields  
2.0.2  
2010-11-05 Add Compact M-Bus Profile; Harmonise Spec. with  
[prEN 13757-3]/[prEN 13757-4]  
U. Pahl  
2.0.3  
2.0.4  
3.0.0  
3.0.1  
4.0.0  
2010-11-17 Revision in AG1  
AG1  
2010-12-17 Comments from members of AG1, Bug fix in Annex B  
2011-01-21 Update Changes from Standard revision  
2011-01-28 Editorial Revision. Release as V3.0.1  
U. Pahl  
U. Pahl  
U. Pahl / A. Bolder  
U.Pahl / A. Bolder  
2013-01-10 New Introduction; Add BSI-support (AFL; new  
2013-05-06 Encryption Mode 7 (dyn. AES) and Mode 13 (TLS);  
2013-07-02 restructure chapters "Supported Device Types" and  
2013-08-19 "Application protocols"; Revision of OBIS-List format;  
2013-08-30 Add new M-Bus Datapoint list, add new section Address  
2013-09-24 handling; Add mandatory support of ELL, Add Mode C  
2013-10-20 support, Remove obsolete Annex E,F and M; general  
2013-10-21 editorial revision, Add new ext. Annex B, E,F,O and int  
2013-10-23 Annex J; Change Annex A to ext. Annex A; expand  
rules for ELL-Access number and TPL-Access number  
Add Timing Diagram fragm. SND-UD  
4.0.1  
4.0.2  
4.1.0  
2014-01-18 Changes according to Enquiry comments (see  
OMS_KommentareVol2Issue4_sortiert2_bearbAG1.doc)  
U.Pahl  
U.Pahl  
U.Pahl  
2014-01-27 Add Note to Annex G; Rename VIF-Type to VIB-Type  
Version 4.0.2 is released  
2016-02-10 Editorial revisions like Decimal-comma;  
Update Terms "serial number, manufacturing number,  
DIN-Fabrication number;  
New chapter 3.3 "Address handling by Adapters";  
4.1: Rename Title "Twisted Pair Connection (M-Bus)";  
4.2.3.2: Ed. Revision + del. Footnote c in Tab.9;  
Tab.10: Ignore FCB in wireless M-Bus;  
Tab.10+Tab.11+Tab.28: add NACK;  
5.1+5.2.1+5.2.4 min. datagram length;  
6.2.6 Msg. counter initialisation with 0;  
7.2.2.1 FCB vs ACC-No;  
7.2.3 clearing of bits “any application error”;  
Tab.22 Bit23 set to 0b;  
7.2.4.3 Add explanation for bits C,B,A,S,R,H,N;  
7.2.4.4 Add explanation for bits N;  
7.2.4.4/7.2.4.5 Notes about ELL-usage for wireless M-  
Bus only;  
OMS GROUP  
2/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Version Date  
Comment  
Editor  
4.1.0  
2016-03-07 4.2.2.4 sync. transmission of static messages  
4.2.3.1 tRO_slow in C2-Mode  
U.Pahl  
(cont.)  
7.2.3+Annex D Update applicable CI-Fields  
8.2.6 new chapter "Descriptors"  
Annex K - new annex "Descriptors"  
8.6 reset of Appl. Errors  
8.6 Appl. Errors unencrypted  
9.1 Encryption of protocols and M-bus data points; Byte  
order of keys  
Tab28: Default value AT/ATO  
9.4.4 techn.revision of message counter  
9.4.7 ed.revision of Key-calc  
Tab.G4 Bug fix in column "hex coded"  
Tab.1 Add CI=54h,55h,66h,67h,68h Application Select  
Protocol  
2016-06-13 Editorial Changes according to  
"20160616_OMS_Table4Comments_OMSS410.docx"  
Change term "dynamic key" to "ephemeral key"  
Change term "static key" to "persistent key"  
1.2 update of version history  
3.1.3.2 case 1) ELLA check by other device  
4.1, 5.2.1, 8.2.1, 9.2.1 5.2.3.1 Add new headline  
"General"  
Move 4.2.2 (without subclauses 4.2.2.1-4.2.2.4) to a  
new sub section 4.3.2.5 "Minimum time delay"  
Move headline 8.1.1. to 8.1 and replace old headline 8.1  
"General Requirements"  
5.2.4 and 8.5 add exception of clock service  
6.2.3 FID for unfragmented messages  
6.2.4; 6.2.7, 9.1; 9.3.1 merge 2 bit fields AT and ATO to  
a 4 bit AT-field  
Move AFL.ML from 6.2.5 to 6.2.8  
Add new 6.2.5 AFL.KI  
7.1 Rename combined Transport/Application layer to  
Transport layer to follows new structure of [EN 13757-7]  
and [EN 13757-3]  
Moving parts of subclause 7.1 to new subclause "8.1  
Overview"  
7.2.1; 7.2.4; Annex D: split CF in CF + CFE  
7.2.4.4 Tab.22 update reserved fields;  
7.2.4.4 Tab.23 extend KeyID to 4 bit  
7.2.4.6 Tab.26+Tab.27 Signed data message was  
withdrawn, Reserved values were updated  
Extend Annex B with Enc.-requirements  
Annex C update M-Bus-Master requirements  
2016-06-13 Update Annex J  
Annex L: Adding Headlines L.1-L.8  
Annex L.4 review Example with NACK  
Bug Fix Annex N  
Change Term "Encryption Mode" by "Security Mode"  
Add new Subclause "8.8 Security Management  
Protocol" and add CI-Fields C3h-C5h in Tab.1  
2016-06-23 Add new subclause 9.4 KeyID  
Replace Annex L.8 by inst. procedure w/o repeater  
4.1.1  
2016-09-16 3.1.3.2 new condition to apply ELLA  
5.2.3 Tab11 new footnote d (SND-NKE)  
U.Pahl  
6.2.5 Revision AFL-KI  
Annex G.2 Update exceptions  
2016-10-21 9.1 update definition of persistent and ephemeral key  
7.3 update Tab.29 add reference/optional TPL for NACK  
OMS GROUP  
3/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Version Date  
Comment  
Editor  
4.1.2  
2016-12-16 9.3.2 update according to comments from BSI  
9.1 Tab.30: add Footnote b  
U.Pahl  
Annex F: update Introduction  
Annex G: Rename title to "Conversion of a Load Profile  
to single data points"  
Version v4.1.2 was released!  
4.2.0  
2019-09-20 1.3 chapter added  
2.2 Tab. 1: CI fields added and changed  
3.1.4 reference updated  
AG1, A. Reissinger  
4.3.1 new note  
4.3.2.3 new reference, addition of 60 s interval  
4.3.3.1, Tab. 9 changed  
4.3.4 changed  
5.2.5 changed  
6 complete chapter optimized for standard references  
7.2.3 changed  
8.1 bullet point added  
8.2 complete chapter added  
8.4.4 paragraph added  
8.4.7 changed  
8.4.8 complete chapter added  
8.6 changed  
8.9 chapter added  
9 chapter content and structure completely revised  
9.1 Tab. 33 updated, column authentication added, Tab.  
34 and 35 changed  
Annexes A, B, E, F, H, J, K changed  
Annex L: changed to “informative”, drawings updated  
Annex M added  
Standard references updated  
Editorial revision  
4.2.1  
4.3.0  
2019-11-23 Release version  
A. Reissinger  
2019-12-17 2.3 Tab. 3 changed  
AG4, A. Reissinger  
4.2.1 chapter added for new Annex P  
and  
4.2.2 last sentence deleted  
5.1 chapter changed for new Annex P, last sentence in  
2020-01-06 first paragraph deleted  
9.2.2 Tab. 38 corrected  
Annex C content deleted  
4.3.1  
2020-03-19 Annex P page revised  
AG4, A. Reissinger  
AG1, A. Reissinger  
and  
2020-05-04 Tab. 15, 33, 34 and 36 changed  
Fig. 15 changed  
8.2.5 changed  
8.8 changed  
and  
“meter(s)/actuator(s)” replaced with “meter” in all  
locations  
2020-05-26 8.1 changed, tab. 25 added  
to 8.4.5.1 new paragraph added  
2020-05-29 Tab. 1 changed  
9.3.2 chapter structure fixed  
2020-06-29 1.2 changed  
Tab. 2 and 3 changed  
Tab. 39 changed  
AG1, A. Reissinger  
A. Reissinger  
4.3.2  
to  
2020-07-09 Release candidate  
OMS GROUP  
4/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Version Date  
Comment  
Editor  
4.3.3  
2020-09-24 8.4.4 changed  
9.2.3 changed  
AG1, A. Reissinger  
9.4.2.1 changed  
and  
Annex L.5 updated  
2020-09-29 3.2 changed  
8.4.5.2 changed  
and  
U. Pahl, T. Banz  
A. Reissinger  
2020-10-02 Editorial changes  
and  
2020-10-13 Integration of several action items:  
AG1, A. Reissinger  
T. Banz  
Introduction of Annex M changed  
5.2.5 changed  
and  
2020-10-22 Editorial changes  
Release  
A. Reissinger  
4.4.0  
4.4.1  
2021-09-08 Table 13: headline corrected  
1.1, 1.2 changed: introduction of sensors  
Tables 2 and 4 changed: introduction of sensors  
T. Banz, A. Reissinger  
D. Matussek  
R. Müller  
Annex C: reference to new external Annex C added  
2021-09-15 Table 24 changed  
A. Reissinger  
A. Reissinger  
and  
2021-09-29 Editorial changes  
and  
D. Matussek, A. Reissinger  
2021-10-21 Release candidate  
A. Reissinger  
4.4.2  
2021-12-01 9.2.3 added  
Table 23: Title and headline changed  
Editorial changes  
AG1, A. Reissinger  
Release  
OMS GROUP  
5/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Version Date  
4.5.0  
Comment  
Editor  
2022-01-31 4.3.2.2, 4.3.2.3 and 4.3.2.4 changed  
7.2.4.4 and 7.2.4.6 changed  
7.2.4.7 added  
AG1, A. Reissinger  
8.4.4 changed  
Table 39 changed  
Figure 16 changed  
2022-02-10 Headline of clause 9.3.2.3 edited  
2022-02-24 2.3 changed  
Table 38: footnote added  
2022-03-18 2,3 changed  
4.3.2.4 changed  
8.4.4 changed  
Table 2 changed  
Table 22 headline changed  
Table 36 headline and note changed  
2022-06-10 Copyright remark added to front page  
2022-07-05 Editorial changes on front page  
2022-07-25 Table 1 changed (network management)  
Table 24 changed (network management)  
Tables 37 and 39 changed (transport key)  
9.2 changed (transport key)  
9.3 changed (communication partner)  
2022-07-29 Introduction of term “OMS end-device”  
2022-08-02 8.10 changed  
Table 38 added  
Table 35 changed  
2022-08-31  
3.1.4 changed  
Table 36 added  
Table 39 changed  
2022-09-14 3.1.2.2 changed  
7.2.4 changed  
7.2.4.5 added  
9.3.2.1 changed  
9.3.7 added  
Table 40 changed  
Table 41 changed  
D,2, D.3 and D.4 changed  
2022-10-08 Editorial update of tables  
1.2 changed  
7.2.4.7 changed  
2022-10-15 Term “key material” replaced by “keying material”  
Term “master-key” replaced by “master key”  
Term “transport key” replaced by “communication  
security key  
Figures 16, 17, 18 changed  
Figures in Annex L changed  
Release candidate  
4.5.1  
2022-11-08 Integration of review comments  
AG1, Achim Reissinger  
to  
2022-11-14 Release  
OMS GROUP  
6/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Version Date  
5.0.0  
Comment  
Editor  
2023-03-28 Complete document: radio modes S (S1, S2) and T  
(T1, T2) removed  
AG1,  
AG1 TF Sensors,  
Achim Reissinger  
to  
1.2 changed  
2.1 revised  
2023-10-14 2.2 changed  
3.1 changed  
4.3 changed  
4.3.2.3 added  
4.3.2.5 deleted  
4.3.3.2 deleted (including table 10)  
7.2.4.5 note added  
8.4.5.1 changed  
8.7 changed  
9.1 changed  
Figure 8 added  
Figure 11 updated  
Figure 13 changed  
Figure 9 deleted  
Table 2 changed for device types 00h, 18h, 1Ah, 1Dh,  
1Eh, 1Fh and footnotes  
Table 41 changed  
Annex C removed  
Annex G changed: G.3 and G.7 added  
Annex J changed: figure revised  
Annex L changed: figures revised  
Annex Q added  
Annex R added  
Release candidate  
5.0.1  
2023-11-14 Consideration of review comments  
AG1, Achim Reissinger  
to  
2024-02-08 Release  
OMS GROUP  
7/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Contents  
OMS GROUP  
8/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
OMS GROUP  
9/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
OMS GROUP  
10/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Temperature Converted Volume Vtc .................................................................110  
OMS GROUP  
11/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Tables  
5
10  
15  
20  
25  
30  
35  
OMS GROUP  
13/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
5
10  
15  
20  
25  
30  
OMS GROUP  
14/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Figures  
5
10  
15  
20  
25  
30  
35  
OMS GROUP  
15/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
OMS GROUP  
16/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
1 Introduction  
1.1 General  
This part describes the minimum Open Metering System requirements for the wired and the  
wireless communication between a slave (OMS end-device) and the (stationary, usually mains  
powered) master (gateway or other communication unit). It covers the Physical Layer, the Link  
Layer, the general requirements for communication security (covered in the Authentication and  
Fragmentation Layer and in the Transport Layer) and the application itself. The Application  
Layer is focused on the M-Bus protocol. But it also supports the DLMS/COSEM protocol and  
an SML-based protocol. Detailed information about the required values and the time resolution  
are given.  
5
10  
This part concentrates on the requirements for OMS end-devices. This specification supports  
both mains powered devices (e.g. electricity meters or actuators) and battery driven devices  
(e.g. water meters, gas meters or thermal energy meters or sensors related to metering).  
The total system overview is provided in Volume 1 [OMS-S1] of the Open Metering System  
specification.1  
15  
An overall glossary with definitions and abbreviations is provided as a separate Annex of  
Volume 1 [OMS-S1] of the Open Metering System Specification (general part).  
The referenced standards and documents (marked with square brackets (e.g.  
[EN 13757-3:2018]) are listed in the Open Metering System Specification (general part).  
20  
25  
Note that according to the use of verbal forms for the expression of provisions in standards  
statements with a “shall” describe mandatory requirements. Statements with a “should”  
describe recommendations.  
Hexadecimal numbers are marked with a suffix "h". Binary coded numbers are marked with a  
suffix "b". Numbers without suffix are decimal numbers except where another coding is  
explicitly declared.  
1.2 Version History  
Issue 1.0 is the very first release with limitation to unidirectional meters only.  
Issue 2.0 amends regulation of the standard to access bidirectional meters or actuators. The  
use of repeaters was substantiated. Parts were adapted to ensure coexistence with NTA 8130.  
30  
35  
40  
Issue 3.0 introduces the synchronous transmission timing to support the long-term use of  
battery powered bidirectional repeaters. Some new CI-Fields were adopted to support the  
consequent use of Short and Long TPL-headers for wireless datagrams.  
Issue 4.0 extends the applicable security methods. It allows compliance with the requirements  
of the German Federal Office for Information Security (Bundesamt für Sicherheit in der  
Informationstechnik BSI) when using Annex E. It applies an update according to the release  
of [EN 13757-3:2013] and [EN 13757-4:2013].  
Issue 4.1 is an improvement of issue 4.0. Besides a lot of minor changes, it contains an  
extension of Application select protocol, a new Annex K with data point descriptors, updated  
Annexes A and B containing encryption requirements for each data point, improved description  
of message counter handling, static messages, and address handling of a radio adapter.  
1 This document shall only be applied in combination with [OMS-S1] Issue 2.0.0 or higher!  
OMS GROUP  
17/143  
       
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Issue 4.2 is an improvement of issue 4.1. Besides many minor changes, reference updates  
and updated annexes it provides an updated credit counter mechanism, a detailed status byte  
handling and a definition of application errors. Especially for the upcoming 2-way use cases of  
Annex M it introduces the application layer security and it defines the applicative behaviour of  
an OMS end-device especially for bidirectional communications. This version introduces  
Annex F to support security profile C.  
5
Issue 4.3 is an improvement of issue 4.2. It introduces two new annexes: Annex M for  
additional optional bidirectional use cases and Annex P for the Wired M-Bus. Consequently,  
Annex C was removed as the master requirements are included in Annex P. The Annexes B,  
E and N were revised as a result of the introduction of Annex M. Annex B contains in its revision  
commands. Annex E supports in its revision IDIS meters. In chapter 8.2.5 the behaviour in  
case of an error was revised. Further changes are listed in the document history.  
10  
Issue 4.4 integrates the communication of sensors related to metering and their device types  
in the new Annex C. The sensor related data points have been added to Annex B.  
15  
20  
Issue 4.5 introduces the new term “OMS end-device”, which covers meters, sensors and  
actuators, introduces harmonised content index values (see 8.4.4), harmonises the message  
application (see 8.10), introduces a new Security profile D (see 9.3.7), applies a new concept  
for command action codes in Annex B, creates new use cases in Annex M and provides a  
correction in Annex P. Additional changes are listed in the document history.  
Issue 5.0 introduces the new Annex Q defining OMS LPWAN, creates new use cases in Annex  
M, removes the definitions for the radio modes S and T and implements changes for the coding  
of sensors according to prEN 13757-3/-7:2023, thus removing Annex C. Additional changes  
are listed in the document history.  
1.3 Reference  
25  
References to other documents are marked with square brackets. They are defined in Volume  
1 [OMS-S1].  
OMS GROUP  
18/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
2 M-Bus Frame Structure  
2.1 OMS-Layer Model  
2.1.1 Overview  
The M-Bus Protocol is separated in several layers based on the OSI 7 Layer Model. This  
document is structured according to the applied communication layers shown in Figure 1.  
5
APL  
Application Layer  
TPL  
Transport Layer  
AFL  
Authentication and Fragmentation Layer  
ELL  
LLC  
Extended Link Layer  
DLL  
Data Link  
Layer  
Logical Link Control Layer  
EN 13757-4  
DLL  
Data Link Layer  
EN 13757-4  
MAC  
EN 13757-2  
Medium Acces Control Layer  
PHY  
PHY  
PHY  
PHY  
Wireless M-Bus Mode C  
EN 13757-4  
OMS LPWAN  
Burst Mode  
OMS LPWAN  
Splitting Mode  
Wired M-Bus  
EN 13757-2  
Figure 1 OMS Layer model  
The Physical Layer and the Data Link Layer are always present for Mode C and wired M-Bus.  
OMS LPWAN (see Annex Q) introduces a new Link Layer containing the Medium Access  
Control Layer (MAC) and the Logical Link Control Layer (LLC). These layers are mandatory  
for OMS LPWAN with the exception of pure MAC layer frames that does not contain any higher  
layers. The MAC and LLC are not introduced by a CI-field.  
10  
15  
The Transport Layer and the applied Application Layer (if existent) are always introduced by  
the Transport Layer’s CI-Field. Optional layers3 like ELL or AFL are introduced by special CI-  
Fields. In such a case the M-Bus-message contains several CI-Fields, chained to one another.  
The OMS Layer Model can be realised in an OMS end-device according to one or more OMS  
modes from the following sub clauses.  
3
[EN 13757-5] supports an additional network layer located between ELL and AFL. This layer is never  
used in the Open Metering System.  
OMS GROUP  
19/143  
         
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
2.1.2 Mode C specification  
An OMS end-device according to this specification includes the layers shown in Figure 2.  
APL  
Application Layer  
TPL  
Transport Layer  
AFL  
Authentication and Fragmentation Layer  
ELL  
Extended Link Layer  
EN 13757-4  
DLL  
Data Link Layer  
EN 13757-4  
PHY  
Wireless M-Bus Mode C  
EN 13757-4  
Figure 2 – Layers included in the “OMS Mode C” specification.  
The PHY, DLL and ELL shall be according to [EN 13757-4].  
5
Further requirements for this implementation are defined in this specification.  
OMS GROUP  
20/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
2.1.3 “OMS LPWAN – Burst Mode” specification  
An OMS end-device according to this specification includes the layers shown in Figure 3.  
APL  
Application Layer  
TPL  
Transport Layer  
AFL  
Authentication and Fragmentation Layer  
LLC  
Logical Link Control Layer  
MAC  
Medium Acces Control Layer  
PHY  
OMS LPWAN  
Burst Mode  
Figure 3 – Layers included in the “OMS LPWAN – Burst Mode” specification.  
The PHY, MAC and LLC shall be according to Annex Q.  
5
Further requirements for this implementation are defined in this specification.  
OMS GROUP  
21/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
2.1.4 “OMS LPWAN – Splitting Mode” specification  
An OMS end-device according to this specification includes the layers shown in Figure 4.  
APL  
Application Layer  
TPL  
Transport Layer  
AFL  
Authentication and Fragmentation Layer  
LLC  
Logical Link Control Layer  
MAC  
Medium Acces Control Layer  
PHY  
OMS LPWAN  
Splitting Mode  
Figure 4 – Layers included in the “OMS LPWAN – Splitting Mode” specification.  
The PHY, MAC and LLC shall be according to Annex Q.  
5
Further requirements for this implementation are defined in this specification.  
OMS GROUP  
22/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
2.1.5 Wired M-Bus specification  
APL  
Application Layer  
TPL  
Transport Layer  
AFL  
Authentication and Fragmentation Layer  
DLL  
Data Link  
Layer  
EN 13757-2  
PHY  
Wired M-Bus  
EN 13757-2  
Figure 5 Layers included in the wired M-Bus specification.  
The requirements for the implementation of wired M-Bus are defined in this specification and  
especially in Annex P.  
5
2.2 Supported CI-Fields  
The CI-Field declares the communication layer, the transport direction (not applicable for lower  
layers like ELL and AFL), and the Application Protocol (if existent). The CI-Field also declares  
the applied type of Transport Layer header ("None", "Short" or "Long", see [EN 13757-7:2018],  
7.2 to 7.5 for details).  
10  
Downlink messages are received by the OMS end-device and uplink messages are transmitted  
by the OMS end-device.  
The following CI-Fields are allowed for OMS-Communication:  
15  
Table 1 List of supported CI-Fields  
Up- or  
Down-  
link  
TPL-  
header-  
Type  
CI-Field Function/Layer  
Protocol or Service  
Application Reset or  
50h d, f  
Select  
Down  
None  
Application Select  
51h d, f  
52h d, f  
Command  
Down  
Down  
None  
None  
M-Bus  
M-Bus  
Selection of Device  
OMS GROUP  
23/143  
       
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Up- or  
Down-  
link  
TPL-  
header-  
Type  
CI-Field Function/Layer  
Protocol or Service  
Application Reset or  
Select  
53h  
Down  
Down  
Down  
Down  
Down  
Long  
None  
Long  
Short  
Short  
Application Select  
Application Select  
Application Select  
Application Select  
Application Select  
Request of selected  
application  
54h d, f  
Request of selected  
application  
55h  
Request of selected  
application  
56h d, e  
Application Reset or  
57h d, e  
Select  
5Ah d, e  
Command  
Command  
Down  
Down  
Short  
Long  
M-Bus  
M-Bus  
5Bh  
Security Management (TLS-Handshake)  
5Fh  
Command  
Down  
Long  
60h  
Command  
Command  
Time Sync  
Command  
Command  
Down  
Down  
Down  
Down  
Down  
Long  
Short  
Short  
Long  
Short  
DLMS b  
61h d, e  
62h d, e  
64h  
DLMS b  
Clock Synchronisation  
SML b  
65h d, e  
SML b  
Response of selected  
application  
66h d  
67h  
Up  
Up  
Up  
None  
Short  
Long  
Application Select  
Application Select  
Application Select  
Response of selected  
application  
Response of selected  
application  
68h  
6Ch  
6Dh  
6Eh  
6Fh  
70h d, f  
71h d, f  
72h  
Time Sync  
Time Sync  
Application Error  
Application Error  
Application Error  
Alarm  
Down  
Down  
Up  
Long  
Long  
Short  
Long  
None  
None  
Long  
Short  
Long  
Short  
Long  
Short  
Long  
Short  
Long  
Clock Synchronisation  
Clock Synchronisation  
Application Error  
Application Error  
Application Error  
Alarm  
Up  
Up  
Up  
Response  
Up  
M-Bus  
74h  
Alarm  
Up  
Alarm  
75h  
Alarm  
Up  
Alarm  
7Ah  
7Ch  
7Dh  
7Eh  
7Fh  
80h  
Response  
Up  
Wireless M-Bus  
DLMS b  
Response  
Up  
Response  
Up  
DLMS b  
Response  
Up  
SML b  
Response  
Up  
SML b  
Pure Transport Layer  
Down  
None  
Network management Protocol (see  
[EN 13757-4:2019] clause 14)  
82h e  
Network management  
Down  
Long  
OMS GROUP  
24/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Up- or  
Down-  
link  
TPL-  
header-  
Type  
CI-Field Function/Layer  
Protocol or Service  
Network management Protocol (see  
[EN 13757-4:2019] clause 14)  
87h e  
88h e  
Network management  
Up  
Up  
Long  
Short  
Network management Protocol (see  
[EN 13757-4:2019] clause 14)  
Network management  
8Ah  
Pure Transport Layer  
Pure Transport Layer  
Extended Link Layer  
Extended Link Layer  
Up  
Up  
Short  
Long  
None  
8Bh  
None  
8Ch c, e  
8Eh c, e  
Up/Down N/A  
Up/Down N/A  
Lower Layer Service (2 Byte)  
Lower Layer Service (10 Byte)  
Authentication and  
Fragmentation Layer  
90h c  
Up/Down N/A  
Lower Layer Service  
Network management Protocol (see  
[EN 13757-4:2019] clause 14)  
92h d, e  
93h d, e  
9Eh  
Network management  
Pure Transport Layer  
Response  
Down  
Down  
Up  
Short  
Short  
Short  
None  
Security Management (TLS-Handshake)  
Security Management (TLS-Handshake)  
9Fh  
Response  
Up  
Long  
None  
None  
None  
None  
None  
Set baud rate to  
300 baud  
B8h d, f  
BBh d, f  
BDh d, f  
BEh d, f  
BFh d, f  
Down  
Down  
Down  
Down  
Down  
Link Layer Control  
Link Layer Control  
Link Layer Control  
Link Layer Control  
Link Layer Control  
Set baud rate to  
2400 baud  
Set baud rate to  
9600 baud  
Set baud rate to  
19200 baud  
Set baud rate to  
38400 baud  
C0h  
Command  
Response  
Response  
Command  
Response  
Response  
Command  
Command  
Down  
Up  
Long  
Short  
Long  
Long  
Short  
Long  
Short  
Short  
Image transfer (see Annex M.2)  
Image transfer (see Annex M.2)  
Image transfer (see Annex M.2)  
Security Information Transport  
Security Information Transport  
Security Information Transport  
Security Information Transport  
Image transfer (see Annex M.2)  
MBAL acc. to prEN13757-8  
C1h  
C2h  
Up  
C3h  
Down  
Up  
C4h  
C5h  
Up  
C6h d, e  
C7h d, e  
Down  
Down  
CFh c, d, e, f M-Bus Adaptation Layer Up/Down N/A  
a
Footnote is obsolete and has been deleted.  
b
Refer also [EN 13757-1:2014], [EN 62056-6-1:2013], [DLMS UA] or [SML-spec]  
These CI-Fields are used for lower layers and may be used in combination with another CI-Field  
These CI-Fields shall not be used for wireless M-Bus Mode C.  
These CI-Fields shall not be used for wired M-Bus.  
These CI-Fields shall not be used with OMS LPWAN.  
c
d
e
f
N/A  
Not applicable  
OMS GROUP  
25/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
2.3 Supported Device Types  
This specification covers only devices with a Device Type listed in Table 2 or Table 3.  
NOTE: The Device Types listed in Table 4 may also be integrated in the Open Metering  
System, but cannot be approved by the OMS-Compliance Test. Therefore, interoperability for  
these Devices Types is not guaranteed.  
5
OMS-Gateways shall accept all the Device Types listed in Table 2 and Table 3 (except device  
types 25h, 31h and 36h). Optionally they may also support Device types listed in Table 4.  
For further details on Device Types refer to [EN 13757-7:2018], 7.5.4, Table 13 Device type  
identification.  
10  
Columns labelled “category” list the mapping from Device Type to corresponding OBIS-  
category / energy type as specified in subclause 3.2 of [DIN 43863-5:2012] (“Identification  
number for measuring devices applying for all manufacturers”).  
OMS GROUP  
26/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Table 2 Device Types of OMS end-device (certifiable with OMS-CT)  
Device Type  
Code  
00h  
02h  
03h  
04h  
06h  
07h  
08h  
0Ah  
0Bh  
0Ch  
0Dh  
15h  
16h  
18h  
1Ah  
1Dh  
1Eh  
1Fh  
28h  
20h  
21h  
Category  
Other  
F
1
7
6
9
8
4
5
5
6
6
9
8
F
F
F
F
F
F
F
F
Electricity meter  
Gas meter  
Heat meter  
Warm water meter (30°C ... 90°C)  
Water meter  
Heat Cost Allocator  
Cooling meter (Volume measured at return temperature: outlet)  
Cooling meter (Volume measured at flow temperature: inlet)  
Heat meter (Volume measured at flow temperature: inlet)  
Combined Heat / Cooling meter  
Hot water meter (≥ 90°C)  
Cold water meter a  
Pressure device c  
Smoke alarm device d  
Carbon monoxide alarm device d  
Heat alarm device d  
Sensor device e  
Waste water meter  
Breaker (electricity) b  
Valve (gas or water) b  
a
Device Type 16h is to be used for cold drinking water that temporarily has been cooled  
or heated in order to achieve the wanted temperature (chilling/antifreeze).  
Annex M, OMS-UC-03 shall be applied for OMS conformance test.  
This device type shall support static datagrams (see 4.3.2.5) with data points acc. to Annex B.  
Transmitted data is used for maintenance of the device, not for the alarm itself.  
Shall be used only in combination with the sub device type ID11!  
b
c
d
e
Table 3 Device Types of other OMS end-devices (prepared for OMS-CT)  
Device Type  
Code  
25h  
31h  
32h  
33h  
36h  
37h  
38h  
Category  
Customer unit (display device)  
Communication controller  
Unidirectional repeater  
Bidirectional repeater  
Radio converter (system side)  
Radio converter (meter side)  
Wired adapter  
E
E
E
E
E
E
E
OMS GROUP  
27/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Table 4 Device Types of not certifiable device  
Device Type  
Code  
01h  
Category  
Oil meter  
F
F
F
E
F
-
Steam meter  
05h  
Compressed air  
09h  
Bus / System component  
Unknown Device Type  
Irrigation water meter  
Water data logger  
0Eh  
0Fh  
10h  
11h  
Gas data logger  
12h  
Gas converter  
13h  
Calorific value  
14h  
F
9
F
F
F
-
Dual register (hot/cold) water meter  
A/D Converter  
17h  
19h  
Room sensor (e.g. temperature or humidity)  
Gas detector  
1Bh  
1Ch a  
22h to 24h  
26h to 27h  
29h  
Reserved for switching devices  
Reserved for customer units  
Garbage  
-
F
F
-
Reserved for Carbon dioxide  
Reserved for environmental meter  
2Ah  
2Bh to 2Fh  
30h  
Reserved for system devices  
34h to 35h  
39h to 3Fh  
E
Reserved  
40h to FEh  
-
-
Not applicable (reserved for wildcard search; refer to [prEN 13757-7:2023],  
7.5.4)  
FFh  
a
Deprecated according to [prEN13757-7:2023]  
OMS GROUP  
28/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
3 Address Handling  
3.1 M-Bus Address  
3.1.1 Overview  
The M-Bus defines several types of addressing. They differ between wired M-Bus (see 3.1.2),  
wireless M-Bus with link layer frame format A (FFA, see 3.1.3) and wireless M-Bus with link  
layer frame format C (FFC, see 3.1.4).  
5
The addresses can be handled in different layers, these are:  
the Data Link Layer (DLL)  
the Extended Link Layer (ELL)  
the Logical Link Control Layer (LLC)  
the Transport Layer (TPL).  
10  
The format of the address Field (A-Field) is different in each of those layers. The addresses  
used in the lower layers (DLL, ELL and LLC) are needed for communication purpose whereas  
the address in the TPL is used for identification of the (metering) application.  
15  
3.1.2 Wired M-Bus  
3.1.2.1 Primary Address  
The A-Field of the wired M-Bus uses a single byte in the DLL, which always contains the  
address of the slave (OMS end-device). The address of the master (gateway) is never used  
because only one master is allowed on the wired M-Bus. This Link Layer Address is called  
Primary Address (PA). The unconfigured Primary Address shall be 0. A valid address in the  
range from 1 to 250 has to be assigned during the configuration process if primary addressing  
is to be used. The addresses from 251 to 255 are used for special purposes and shall be  
supported in accordance with [EN 13757-2:2018].  
20  
PA=  
1
Gate-  
OMS  
end-device  
way  
(GW)  
(OED)  
PA= ALA=  
1
OED  
Figure 6 Primary Address for wired M-Bus (Example)  
25  
The slave (OMS end-device) shall always respond with its own Primary Address even in the  
case it is addressed from the master (gateway) by Secondary Address or addressed by  
broadcast address.  
3.1.2.2 Secondary Address  
The Secondary Address is an enhancement of the limited address space of the Primary  
Address. It defines the Application Layer Address (ALA) and shall be worldwide unique for all  
types of OMS end-devices. Therefore, it shall be assigned by the OMS end-device  
manufacturer and shall not be changeable by any other party (e.g. MSO).  
30  
OMS GROUP  
29/143  
         
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
This rule is not applicable for adapters (e.g. pulse adapters, encoder adapters or protocol  
converters). If an adapter is used to connect an OMS end-device with the M-Bus, the adapter  
should transmit the OMS end-device address. For this purpose, the serial number of the OMS  
end-device replaces the Identification Number (part of the ALA) of the M-Bus-adapter. In this  
case the unchangeable Identification Number of the adapter shall additionally be transmitted  
in case of M-Bus application protocol with the data point “Fabrication Number" (ID1!) to avoid  
unsolvable address collisions.  
5
10  
15  
The structure of the Secondary Address is described in subclause 3.1.5. The usage of the  
Secondary Address is indicated by a Primary Address 253.  
The selection of an OMS end-device by Secondary Address (refer to [EN 13757-7:2018], 8.4)  
and the wildcard search (refer to [EN 13757-7:2018], 8.6.3) shall be supported.  
An adapter should support the enhanced selection with Fabrication Number (refer to  
[EN 13757-7:2018], 8.5).  
OMS end-devices that do not support the enhanced selection shall ignore the enhanced  
selection command of the master (gateway).  
PA= ALA=  
253 OED  
Gate-  
OMS  
end-device  
way  
(GW)  
(OED)  
PA= ALA=  
1
OED  
Figure 7 Secondary Addresses for wired M-Bus (Example)  
The ALA of the OMS end-device shall always be in each M-Bus-message of the slave (OMS  
end-device). The master (gateway) shall apply the ALA of the OMS end-device at least in case  
of encryption or during the selection (refer to [EN 13757-7:2018]) of the slave (Figure 7).  
20  
NOTE 1: The address field of the ALA exists only if a Transport Layer with Long TPL-header  
is used (see 2.2 and Annex D).  
NOTE 2: When a valid Primary Address is applied or the slave (OMS end-device) is clearly  
selected, then the (unencrypted) message of the master (gateway) may not contain a  
Secondary Address (ALA) (Figure 6).  
25  
If an adapter uses encrypted data transfer, then its Fabrication Number shall be transmitted in  
the unencrypted area.  
3.1.3 Wireless M-Bus (Frame Format A)  
3.1.3.1 General  
The frame format A shall be used in case of the wireless M-Bus Mode C.  
30  
35  
3.1.3.2 Link Layer Address (LLA)  
The address field of the Data Link Layer always contains the address of the sender. This can  
be the address of the OMS end-device/repeater/gateway (in case of an integrated radio  
interface) or the address of the RF-Adapter (which connects the hosted device to the radio  
channel). Its structure is described in subclause 3.1.5. The Link Layer Address shall be used  
in each wireless M-Bus-datagram.  
OMS GROUP  
30/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
LLA= ALA=  
GW OED  
Gate-  
way  
OMS  
end-device  
(OED)  
(GW)  
LLA=  
OED  
Figure 8 Addresses for wireless M-Bus (without ELLA)  
The Link Layer Address shall be unique worldwide for all wireless M-Bus OMS end-devices.  
Therefore, it shall be assigned by the manufacturer and shall not be changeable by any other  
party (e.g. MSO). The assignment of an additional address (if necessary, e.g. when using an  
external RF-Adapter) has to be applied in the Transport Layer using an Application Layer  
Address (see 3.1.3.4).  
5
3.1.3.3 Extended Link Layer Address (ELLA)  
The address field of the Extended Link Layer always contains the destination address (OMS  
end-device/adapter/gateway). It is only used for wireless M-Bus. Its structure is described in  
subclause 3.1.5.  
10  
The ELLA only exists if a long Extended Link Layer is applied (see 5.2.2.2).  
A received datagram with an ELLA not matching to its own Link Layer Address shall be  
ignored, even if the ALA is correct.  
The Extended Link Layer Address is only required in the following cases.  
15  
20  
1. Addressing of a not allocated communication partner  
To avoid conflicts in bidirectional radio communication it is essential that an OMS end-device  
is allocated to only one dedicated gateway. This allocated gateway should not use the ELLA  
to contact the OMS end-device (except when case 2, 3 or 4 is applicable). Any other device  
(such as a service tool) shall always transmit the ELLA to identify itself as a non-allocated  
communication partner on the OMS end-device and compare the received ELLA with its own  
address. An OMS end-device response (RSP-UD, ACK, NACK) without ELLA shall only be  
accepted by the allocated gateway.  
2. Response to a request with ELLA  
If a device receives a datagram with an ELLA (identical to its own Link Layer Address), it shall  
respond with an ELLA (holding the Link Layer Address of the other device). If the received  
ELLA does not fit to its own Link Layer Address, the datagram shall be ignored.  
25  
3. Fragmented Messages  
If a message is fragmented (by using the AFL - see clause 6), each fragment (datagram) shall  
apply the ELLA. This is required because the Application Layer Address (ALA) will only be  
present in the first fragment. Even the request (REQ-UD2) and the acknowledge (ACK) of the  
concerning fragment shall apply the ELLA of the communication partner (also see Annex L).  
30  
NOTE: The first REQ-UD2 of a fragmented message may contain no ELLA (but always an  
ALA). The first RSP-UD as well as all following fragments of this message require the ELLA.  
4. Message to an RF-Adapter  
35  
If a gateway responds to an OMS end-device using an RF-Adapter, the gateway shall apply  
the ELLA in the datagram (see Figure 10).  
Message types SND-NR, SND-IR, ACC-NR, and ACC-DMD should not apply the ELLA.  
OMS GROUP  
31/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Figure 9 and Figure 10 show the usage of the ELLA beside the other address fields.  
LLA= ELLA= ALA=  
GW OED OED  
Gate-  
OMS  
end-device  
way  
(GW)  
(OED)  
LLA= ELLA=  
OED GW  
Figure 9 Addresses for wireless M-Bus (with ELLA)  
PA= ALA=  
253 OED  
LLA= ELLA= ALA=  
GW RFA OED  
RF-  
Gate-  
way  
(GW)  
OMS  
end-device  
(OED)  
adapter  
(RFA)  
PA= ALA=  
LLA= ELLA= ALA=  
RFA GW OED  
1
OED  
Figure 10 Addresses for wired and wireless M-Bus (with ELLA, example)  
5
10  
15  
3.1.3.4 Application Layer Address (ALA)  
The address field of the Transport Layer always contains the address of the application (OMS  
end-device). Its structure is described in subclause 3.1.5.  
The Application Layer Address shall always be present in downlink messages (to the OMS  
end-device) and in uplink messages (from the OMS end-device), if an external RF-Adapter  
(Device Type 37h) is used. For OMS end-devices with an integrated radio module the Link  
Layer Address acts as Application Layer Address as well (see Figure 8).  
A received datagram with a not matching ALA (if existent) shall be ignored by the OMS end-  
device, even if the ELLA is correct.  
NOTE 1: The RF-Adapter can also be addressed directly using the ALA with the RF-Adapter  
address.  
NOTE 2: The address of the communication partner of the OMS end-device (like gateway,  
repeater or service tool) is never applied in this address field.  
NOTE 3: The address field of the ALA only exists, if a Transport Layer with Long TPL-header  
is used (see 2.2 and Annex D).  
20  
NOTE 4: The additional usage of an ALA is also allowed (but not requested), when LLA and  
ALA are identical.  
The detection of the ALA shall be processed according to the algorithm in Figure 11.  
OMS GROUP  
32/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Figure 11 Detection of the ALA  
3.1.4 Wireless M-Bus (Frame Format C)  
3.1.4.1 General  
5
The frame format C in the LLC layer shall be used together with the M-Bus MAC layer in case  
of OMS LPWAN (see Annex Q). It has a flexible design and can contain both, the transmitter  
address (TXA) and the receiver address (RXA). This makes the use of the ELL (as described  
in 3.1.3.3) obsolete. The application address (ALA) in the TPL is only needed in case an  
external RF-Adapter (Device Type 37h) is used.  
10  
The TXA is a functional replacement of the LLA. The RXA is a functional replacement of the  
ELLA. The flexible structure of the frame format C (FFC) allows to apply them only if needed  
with help of the controlling bits in the LC[0]-field (see Annex Q, Q.4.2.2 LC-Field).  
Figure 12, Figure 13 and Figure 14 provides an overview of different address usage with FFC.  
OMS GROUP  
33/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
RXA=  
OED  
Gate-  
way  
OMS  
end-device  
(OED)  
(GW)  
TXA=  
OED  
Figure 12 Address usage in FFC for an allocated gateway  
TXA= RXA=  
GW OED  
Gate-  
OMS  
end-device  
way  
(GW)  
(OED)  
TXA= RXA=  
OED GW  
Figure 13 Address usage in FFC for a not allocated gateway  
NOTE: An allocated gateway may also send the TXA-field with its own address if it sets the  
5
RRX bit (see Annex Q, Q.4.2.2 LC-Field) in downlink.  
PA= ALA=  
253 OED  
RXA= ALA=  
RFA OED  
RF-  
Gate-  
way  
(GW)  
OMS  
end-device  
(OED)  
adapter  
(RFA)  
PA= ALA=  
TXA=  
RFA  
ALA=  
OED  
1
OED  
Figure 14 Address usage in FFC with RF-Adapter  
3.1.4.2 Transmitter Address (TXA)  
The transmitter address is contained in the LLC layer within the M-Field and the A-Field if  
indicated by the Transmitter Address Present” (TAP) bit in the LC[0]-field. Its structure is  
described in subclause 3.1.5. In uplink direction it contains the address of the sender that is  
either the OMS end-device or the RF-Adapter. In downlink direction it contains the sender  
address, i.e., the address of the gateway or the communication partner.  
10  
The TXA is not mandatory in all datagrams. It can be avoided in the following cases:  
15  
1. Uplink MAC frame types without LLC (see Annex Q, Table Q.74 MAC Frame types)  
2. Downlink frames from an allocated gateway  
The TXA (like the LLA, see 3.1.3.1) shall be worldwide unique for all wireless M-Bus OMS end-  
devices, RF-Adapters and gateways. Therefore, it shall be assigned by the manufacturer and  
shall not be changeable by any other party (e.g. MSO).  
20  
3.1.4.3 Receiver Address (RXA)  
The receiver address is contained in the LLC layer within the M2-Field and the A2-Field if  
indicated by the “Receiver Address Present” (RAP) bit in the LC[0]-field. Its structure is  
OMS GROUP  
34/143  
       
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
described in subclause 3.1.5. It contains the destination address in uplink (e.g. the gateway)  
and downlink (the address of the OMS end-device or the RF-Adapter) direction.  
The RXA is not mandatory in all datagrams. It can be avoided in the following cases:  
1. Uplink MAC frame types without LLC (see Annex Q, Table Q.74 MAC Frame types)  
2. Unsolicited uplink frames  
5
3. Uplink frames inside a downlink communication session(see Annex Q, Q.3.3.5)  
where the communication partner did not request the uplink receiver address with the  
RRX bit of the LC[0]-field (see Annex Q, Q.4.2.2 LC-Field).  
3.1.4.4 Application Layer Address (ALA)  
10  
The ALA is the address field in the TPL. Its structure is described in subclause 3.1.5.  
The address of the OMS end-device is located in different address fields depending on the  
uplink or downlink and the usage of an internal/integrated or external radio module. Table 5  
depicts the location of the OMS end-device address for the different cases.  
Table 5 Location of the OMS end-device address  
Direction  
Uplink  
TXA  
Downlink  
RXA  
Integrated radio  
External RF-Adapter  
ALA  
ALA  
15  
A received datagram including a not matching ALA shall be ignored by the OMS end-device.  
NOTE 1: The RF-Adapter can also be addressed directly using the ALA with the RF-Adapter  
address.  
NOTE 2: The address field of the ALA only exists if a Transport Layer with Long TPL-header  
is used (see 2.2 and Annex D).  
20  
3.1.5 M-Bus Address Elements  
The LLA, the ELLA, the TXA and the RXA for wireless M-Bus as well as the ALA for both wired  
and wireless M-Bus always consist of these four parts:  
Identification Number (Device ID)  
Manufacturer ID  
Version  
25  
Device Type  
Usage of these elements shall be in accordance with [EN 13757-7:2018], 7.5.1 to 7.5.4.  
The registered FLAG ID from the DLMS UA shall be used as the Manufacturer ID  
(https://www.dlms.com/flag-id/).  
30  
35  
The Version field is not restricted in use for naming the software version. It may apply also for  
other address purposes like coding of the manufacturer's location as long as it grants a  
worldwide unique addressing of this OMS end-device. Additional OMS end-device  
identification schemes like customer number or OMS end-device location may be implemented  
via corresponding data records within the Application Layer.  
See 2.3 for the limitation of the Device Type.  
The order of the address elements differs between the lower layer addresses (LLA, ELLA,  
TXA, RXA) and the ALA.  
The ALA shall apply to the structure as given in [EN 13757-7:2018], 7.4.  
The lower layer addresses shall apply to the structure as given in [EN 13757-7:2018], 8.3.  
OMS GROUP  
35/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Address examples can be found in Annex A of [CEN/TR 17167:2018] and Annex N of this  
specification.  
3.2 DIN Address  
[DIN 43863-5:2012] defines a common structure Meter-ID. This DIN Address structure is the  
base for meter management.  
5
The structure of the DIN Address is shown in Table 6.  
Table 6 Structure of the DIN Address  
Digit  
14  
13  
12  
11  
10  
09  
08  
07  
06  
05  
04  
3
03  
3
02  
4
01  
4
Meaning  
OBIS Manufacturer ID Fabrication DIN-Fabrication Number  
7
Block  
Example  
Q
D
S
0
1
1
1
2
2
The DIN Address may be used on the label of a metering device. For the Link or Transport  
Layer of the wired or wireless M-Bus only the M-Bus addresses are allowed. However, there  
is a clear relation between the ALA and the DIN Address and one address type can be  
converted from one to another. The address conversion shall be done according to the  
following rules.  
10  
Energy type (e.g. electricity) based on OBIS code value group A.  
OBIS-cat. 4  
(Note that categories “E” and “F” are listed in DIN 43863-5:2012, but  
only energy type “F” for “Other media” is listed in Blue Book ed. 13 of  
DLMS User Association.)  
For conversion between the address types use Table 2, Table 3, and  
Table 4 in 2.3. These tables list the assigned OBIS- category / energy  
type for each M-Bus Device Type.  
Manufacturer ID  
Fabrication Block  
This field corresponds to the Manufacturer ID of the M-Bus Address. Note  
that the Manufacturer ID of the DIN Address is presented with ASCII-  
letters (A-Z, upper case only), whereas the M-Bus uses a 2 byte binary  
code. Conversion between both is described in [EN 13757-7:2018],  
7.5.2. The most significant bit of the M-Bus Manufacturer ID is pre-set to  
0 (Hard address).  
According to [DIN 43863-5:2012] the usage of the Fabrication Block is  
manufacturer specific. This is comparable with the Version Field of the  
M-Bus Address. For conversion between M-Bus Address and the DIN  
Address the Fabrication Block holds the same content as the Version  
Field (and vice versa).  
DIN-Fabrication  
Number  
The DIN-Fabrication Number contains the serial number of the meter. It  
is equal to the Identification Number of the M-Bus Address. For the  
conversion between address types the DIN-Fabrication Number of the  
DIN Address gets the same content like the Identification Number of the  
M-Bus Address (and vice versa).  
Each M-Bus Device Type can be unambiguously converted to an OBIS-Category. Reversely,  
multiple Device Types are mapped to a single OBIS- category / energy type. Therefore, a  
conversion can only be unique, if all Device Types with the same OBIS- category / energy type  
differ in Identification Number, Manufacturer ID or Version. Consequently, the manufacturer  
shall ensure that the M-Bus Addresses of all of their meters have unique combinations of  
Identification Number and Version within the same OBIS- category / energy type.  
15  
4 Corresponds to “OBIS- category / energy type”  
OMS GROUP  
36/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
The DIN Address may also be made available as a data point on the OMS end-device  
interface, as defined in 8.4.5.2.  
3.3 Address Handling by Adapters  
An RF-Adapter or an M-Bus-Adapter transports the address of the hosted OMS end-device.  
Figure 15 specifies how the adapter shall detect and convert the OMS end-device address to  
an M-Bus-address.  
5
In case the adapter identifies the hosted OMS end-device by its DIN-Address, the conversion  
to an M-Bus Address may not be unique. Table 7 shows recommended default values for a  
conversion from OBIS-category to Device Type. A better applicable Device Type can  
however be used instead. The selected Device Type shall be linked to the given OBIS-  
category according to Table 2, Table 3, and Table 4.  
10  
Table 7 Default Device Type in case of DIN-Address conversion  
Category Default M-Bus Device Type  
Code  
1
2
3
4
Electricity meter  
02h  
-
-
-
-
Heat Cost Allocator  
08h  
Cooling meter  
(Volume measured at return temperature: outlet)  
5
0Ah  
6
Heat meter  
04h  
03h  
07h  
06h  
-
7
Gas meter  
8
Water meter  
9
Warm water meter (30°C … 90°C)  
A
B
C
D
E
F
-
-
-
-
-
-
-
Bus / System device  
0Eh  
0Fh  
Unknown Device Type  
OMS GROUP  
37/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Figure 15 Address handling of an RF or M-Bus adapter  
OMS GROUP  
38/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
4 Physical Layer  
4.1 General  
Data shall be collected from the OMS end-devices using two-wire M-Bus via pull mode, or  
wM-Bus (wireless M-Bus) via push mode. This means that OMS end-devices transmit metering  
data by radio in regular intervals or they have to be queried via wired M-Bus by the gateway.  
Optionally the gateway may also query metering data from bidirectional wireless M-Bus OMS  
end-devices.  
5
4.2 Wired Communication (Wired M-Bus)  
4.2.1 General  
10  
Normative and informative requirements for the M-Bus are defined in Annex P and [EN 13757-  
2:2018].  
4.2.2 Electrical Specification  
For wired connections the Physical Layer M-Bus according to the European Standard  
[EN 13757-2:2018] is used. It is a two-wire system, which optionally also provides power to the  
devices. The number of wired M-Bus devices that can be controlled by a gateway, shall be  
specified by the manufacturer. The minimum requirements are those of a Mini-Master as  
described in [EN 13757-2:2018].  
15  
4.2.3 Hardware Connections and Wiring  
The bus interfaces of the slaves are polarity independent, which means that the two bus lines  
can be reversed without affecting the operation of the slaves. Besides protection aspects, this  
also leads to a simplified installation of the bus system. In order to maintain correct operation  
of the bus in case of a short circuit of one of the slaves, these shall have a serial resistor with  
a total nominal value of 430±10 in the bus line. This limits the current in case of a short  
circuit to a maximum of 100 mA (42 V / 420 ). For the requirements for wiring and installation  
refer to [EN 13757-2:2018] and Annex P.  
20  
25  
4.3 Wireless Communication (Wireless M-Bus)  
4.3.1 Modes and Requirements  
[EN 13757-4:2019] describes different variants for wireless metering communication. They  
cover many types of metering communication including mobile and stationary readout modes.  
The Open Metering System scenario requires a stationary receiver. This document extends  
[EN 13757-4:2019] to allow OMS LPWAN and optional single hop relaying for radio range  
extension. Multi hop relaying of these data via other (optionally battery powered) OMS end-  
devices is not supported by this specification.  
30  
35  
As for the various modes described in [EN 13757-4:2019], only the modes C1 and C2 are  
supported by this specification. Additionally, the wireless M-Bus mode OMS-LPWAN defined  
in Annex Q is supported too. These modes operate in duty-cycle limited sub bands of the 868  
870 MHz license free frequency range. The duty cycle is not a limiting factor for the Open  
OMS GROUP  
39/143  
               
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Metering System but limits the band occupation time for all systems operating in these  
frequency bands.  
NOTE 1: OMS LPWAN increases the robustness against disturbers by applying FEC. This  
results in a higher channel occupancy.  
5
A limitation of the total average transmission duty cycle per hour to 0,02 % is recommended  
for Mode C. This is required to limit the collision rate e.g. in dense situations. CEPT/ERC/REC  
70-03 E, refer to [ERC 70-03], and ETSI EN 300220-1 [ETSI EN 300 220-1] describe further  
requirements for the Physical Layer.  
NOTE 2: The OMS LPWAN duty cycle limitations are provided in Annex Q.  
10  
15  
There are unidirectional modes like C1, UL-S1 or UL-B4 where the OMS end-device frequently  
(seconds to hours) transmits datagrams containing OMS end-device identification together  
with metered data. This unidirectional function is sufficient to support all mandatory  
communication for an OMS end-device within the framework of the Open Metering System.  
There is also compatible bidirectional enhancement of the respective unidirectional mode. It  
enables an optional gateway to OMS end-device communication following an OMS end-device  
to gateway datagram. [EN 13757-4:2019] describes all requirements (also applicable for  
testing conditions) for the supported modes C1 and C2. The same applies for the OMS LPWAN  
sub-modes of Annex Q.  
Due to required battery lifetime, most meters and some actuators cannot support a continuous  
receive mode. A gateway initiated (“Pull”) communication with the OMS end-device is possible.  
But any such a gateway to OMS end-device communication is typically limited to a time slot  
directly following an OMS end-device to gateway communication (except for mains powered  
devices). Since the OMS end-device transmits frequently, the resulting transmission delay  
(varying from seconds to hours) seems acceptable. An actuator shall transmit at least its  
unique ID and its status and wait after each transmission for a possible datagram from the  
gateway as described in [EN 13757-4:2019]. For a breaker, as the typical actuator, the  
maximum time interval between such transmissions shall be the same as the maximum time  
interval for meter transmissions of the same medium (i.e. electricity or others) as shown in  
20  
25  
30  
35  
40  
45  
For certain communication situations between the gateway and an optional actuator this might  
not be sufficient. Thus, actuators with faster reaction time requirements should be mains  
powered.  
Link Control Bits in the MAC Layer, Extended Link Layer or Configuration Field of the OMS  
end-device datagram signal to the gateway whether the device can receive data (i.e.  
implements the bidirectional mode) and whether it can receive continuously or only  
immediately after each transmission.  
The OMS end-device and gateway manufacturers decide which of the supported mode are  
implemented in their products. This requires clear labelling of the devices as well as the  
respective data sheets so that the customer has the possibility to choose between  
interoperable combinations. A gateway may support communication with one, several, or with  
all of the radio communication modes mentioned.  
Countries being members of CEPT (e.g. EU, EEA and more) shall use the frequencies  
specified in [EN 13757-4:2019], which are based on CEPT/ERC/REC 70-03 [ERC 70-03]  
(except Russia). Other countries where these frequencies are not allowed shall use the  
alternative frequencies defined in Annex O of this document.  
OMS GROUP  
40/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
4.3.2 Wireless Data Transmission Intervals  
4.3.2.1 Synchronous versus Asynchronous Transmission  
OMS end-devices shall use the strictly synchronous transmission scheme as specified  
for Mode C in [EN 13757-4:2019], 12.6.2 and  
for OMS LPWAN in Annex Q, Q.2.4.6.4 and Q.2.5.6.3.  
5
The synchronous transmission is signalled by the synchronous bit S. The synchronous  
transmission timing can be predicted using the Access number. The position of this information  
is located in different layers of the datagram depending on the applied wireless M-Bus mode  
Mode C: If the Extended Link Layer is present, Access Number and Synchronous Bit  
(see 5.2.2.2.3) in the ELL shall be used for synchronous timing. Otherwise the Access  
Number of the Transport Layer and the Synchronous Bit in the Configuration Field shall  
be applied.  
OMS LPWAN: This wireless M-Bus mode provides a Logical Link Control Layer (LLC)  
using Frame format C. This LLC combines elements of DLL and ELL. The Synchronous  
Bit and the Access number of the LLC shall be used (see Annex Q, Q.4)  
10  
15  
As described in [EN 13757-4:2019], 12.6.2, additional asynchronous transmissions are  
allowed. The Access Number handling of asynchronous transmissions is specified in  
[EN 13757-7:2018], 7.5.5.2 and pictured in Figure 16.  
t
tACC  
Figure 16 Access number for synchronous and asynchronous transmissions  
20  
Legend:  
S
S = 1: synchronous datagram; S = 0: asynchronous datagram  
Access Number  
ACC  
tACC  
individual transmission interval from the datagram with the Access  
Number ACC = n to the next synchronous transmission with ACC = n+1  
25  
30  
The synchronous transmission shall be one of the message types SND-NR, ACC-DMD, or  
ACC-NR (see Table 16). If the nominal transmission interval (refer to [EN 13757-4:2019], 3.12  
and 12.6.2) is smaller than the selected update interval of consumption data (see Table 8),  
then one or several ACC-NR may be used for synchronous transmission between the  
synchronous transmissions of the SND-NR. The ratio of ACC-NR versus SND-NR  
(respectively ACC-DMD in case of alert) shall be n to 1 to allow a reception of every nth  
datagram only (with n = 0 15) by a battery operated receiver. The ratio shall not be changed  
after the installation of the OMS end-device.  
OMS GROUP  
41/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
The start of the first synchronous transmission shall be stochastic. It is not allowed to fix the  
synchronous transmission exactly to a common event like a special time or a power-up after a  
voltage breakdown. This is required to avoid a concurrent use of the radio channel by many  
OMS end-devices. Refer also to subclause 7.2.2.1.  
5
Asynchronous transmissions are intended for any transmission outside the synchronous  
transmission time slot. OMS end-device message types RSP-UD, ACK, NACK, SND-IR shall  
be asynchronously transmitted. Nevertheless, message types SND-NR, ACC-DMD, or  
ACC-NR may be asynchronously transmitted as well (see Table 16).  
A bidirectional OMS end-device should provide a reception window (after a transmitted  
synchronous datagram) per interval tNOM (max) according to [EN 13757-4:2019], 12.6.2, Table  
36 Maximum values of nominal transmission interval. The bidirectional OMS end-device shall  
not provide less reception windows as defined in 4.3.4.  
10  
4.3.2.2 Interval of Consumption Data  
OMS end-devices shall provide a minimum data granularity (see Table 8) of the consumption  
data points as required in 8.4.4 for billing purpose. This can either be done with a regular  
update of those data points (high data actuality, typical for Mode C) or by providing the  
necessary granularity with a collection of periodical values (lower data actuality, typical for  
OMS LPWAN).  
15  
20  
NOTE: A data actuality of e.g. 24 hours means that at least one time a day an update of the  
data in the AMMHES is provided.  
It is recommended to transmit an update of consumption data with every synchronous  
transmission. However, the consumption data shall be updated at least with the update interval  
maximum as listed in Table 8.  
Table 8 Update interval of consumption data for billing  
Minimum data  
granularity  
[hours]  
Update interval  
Update interval  
Device  
maximum [min] a maximum [hour] b, c  
for Mode C  
7,5  
for OMS LPWAN  
Electricity  
0,25  
1
12  
12  
12  
12  
12  
12  
-
Gas  
30  
Heat (district heating)  
Water / Warm water  
Heat cost allocators  
1
30  
24  
24  
240  
240  
Heat / Cold (sub metering) 24  
240  
c
Repeater  
-
240  
a
Additional to this value a tolerance of +3,1258 % shall be accepted. This tolerance  
includes the scatter of the nominal transmission interval and an additional clock  
uncertainty of 250 ppm acc. to [EN 13757-4:2019], 12.6.2.  
The required data granularity can be achieved either with a smaller update interval or with  
providing the respective number of recent values, see formula (1).  
b
c
The values refers to data of the repeater itself. Not for repeated datagrams!  
25  
For consumer information that needs a high data actuality the UC-07 of Annex M can be  
supported. This use case provides a separate requirement for the consumption data update  
interval maximum.  
The update interval maximum results from the aimed data actuality respecting a redundancy  
factor of 2. This redundancy factor is needed to guarantee a successful transmission for a  
typical reception probability of more than 95%. The aimed data actuality is 24 hours for OMS  
LPWAN. For Mode C it is identical to the minimum data granularity, e.g. 1 hour for a gas meter.  
30  
OMS GROUP  
42/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Due to the higher energy consumption of OMS LPWAN transmissions it makes sense to  
provide the necessary granularity with the collection of periodical values in one message using  
e.g. a Compact Profile (see Annex G). In this case the transmission of a related time stamp is  
required (see “DT1!P” in Annex B). The number of the necessary contained values (NDP)  
depends on the selected update interval (TU) and on the aimed data granularity (DG). It also  
shall take the redundancy factor (RF) into account. This results in the following formula (1):  
5
NDP = TU / DG * RF  
(1)  
Example:  
A gas meter having a transmission interval of 12 hours (which is the allowed maximum) shall  
put NDP = 12h / 1h * 2 = 24 values in each consumption data message.  
10  
A water meter that has to provide a (higher) data granularity of 1 hour with a transmission  
interval of 3 hours shall put NDP = 3h / 1h * 2 = 6 values in each consumption data message.  
4.3.2.3 Interval of Sensor Data  
An update of sensor data with every synchronous transmission is recommended. However,  
the sensor data shall be updated at least with the update interval maximum as listed in Table 9.  
15  
See Table 9 for mandatory sensor data update periods:  
Table 9 Update interval of Sensor data for different devices  
Device  
Device-  
Type  
Sub-  
Device-  
Minimum  
data  
Update  
interval  
Update  
interval  
Immediate update b  
[EN13757 Type  
granularity maximum maximum  
-7:2023,  
7.5.4]  
[EN13757 [hours] a [min] a [hours] a, c  
-3:2023,  
6.5.2]  
for Mode C for OMS-  
LPWAN  
change in RH1! >=  
5%rH  
Humidity Sensor  
1
1
30  
12  
Moisture Sensor  
2
3
1
1
30  
30  
12  
12  
change in MO1! >= 5%  
change in TC4! >= 1°C  
Temperature Sensor  
% change in LT1! Or  
LT2! >= 10  
Light Sensor  
5
6
1
1
30  
30  
12  
12  
change in RF1! >=  
1 mm  
Rainfall Sensor  
pH Sensor  
7
8
1
1
30  
30  
12  
12  
-
-
Anemometer  
Glass Break  
Detector  
9
1
30  
12  
12  
-
Door/Window  
Contact Sensor  
10  
12  
360  
change in MM16!  
Locked  
Door/Window  
Detector  
11  
12  
360  
12  
change in MM16!  
Water Leakage  
Detector  
12  
13  
14  
1
1
1
30  
30  
30  
12  
12  
12  
change in MM3! Bit10  
change in VC1! >=  
100µg/m³  
Air Quality Sensor  
CO2 Sensor  
change in CC2! >=  
10ppm  
Turbidity Sensor  
CO Alarm Device  
15  
18  
1
4
30  
12  
12  
% change in TB1! >= 10  
change in MM14!  
1Dh d  
120  
OMS GROUP  
43/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Device  
Device-  
Type  
Sub-  
Device-  
Minimum  
data  
Update  
interval  
Update  
interval  
Immediate update b  
[EN13757 Type  
granularity maximum maximum  
-7:2023,  
7.5.4]  
[EN13757 [hours] a [min] a [hours] a, c  
-3:2023,  
6.5.2]  
for Mode C for OMS-  
LPWAN  
Smoke Alarm Device 1Ah d  
19  
20  
21  
4
4
1
120  
120  
30  
12  
12  
12  
change in MM15!  
change in MM17!  
change in MM13!  
Heat Alarm Device  
1Eh d  
18h d  
Pressure Device  
a
Additional to this value a tolerance of +3,1258 % shall be accepted. This tolerance includes the scatter of the  
nominal transmission interval and an additional clock uncertainty of 250 ppm acc. to [EN 13757-4:2019],  
12.6.2.  
b
c
d
Recommendation for an event-based trigger, in which the updated sensor data is sent within the next  
synchronous telegram.  
The required data granularity can be achieved either with a smaller update interval or with providing the  
respective number of recent values, see formula (1).  
Either the listed device type is used or the sub device type is used together with the device type 1Fh.  
Data granularity, update interval maximum for mode C and update interval maximum for OMS-  
LPWAN are explained in 4.3.2.2.  
4.3.2.4 Interval of Installation Data  
The optional transmission of installation datagrams (with C = 46h) should happen only after a  
manual installation start event (e.g. push of installation button). Installation datagrams shall be  
transmitted according to [EN 13757-4:2019], 12.6.1. A SND-IR shall be sent within 60 s after  
the manual start event. Note that the duty cycle shall be respected also during installation  
mode. If the installation datagram contains fixed data for meter management (like OBIS code  
definitions, as defined in [EN 13757-3:2018] Annex H.3), it shall be marked as a static message  
(see [EN 13757-7:2019], Table 21).  
5
10  
4.3.2.5 Interval of Management Data  
If an OMS end-device provides special management data (e.g. ownership number, OBIS  
definition codes or other data, which are not frequently changing), it can transmit this data in a  
static message. Static messages shall be marked as described in [EN 13757-7:2019], Table  
21 and shall be sent at least with the maximum access opportunity delay according to Table 12  
but not more than five times a day in a synchronous time slot to support battery driven receivers  
(e.g. battery driven repeater). The transmission of the static messages leads to a gap between  
the two adjacent SND-NR transmissions with dynamic data, which may lead to a larger update  
interval maximum (see Table 8 and Table 9). This will be accepted.  
15  
20  
NOTE: It is not recommended to transport consumption data with a static message. But the  
definition of message content is manufacturer specific.  
4.3.3 Access Timing of a Bidirectional OMS end-device  
4.3.3.1 Access timing for Mode C2  
An OMS end-device signals its own accessibility in the Link Control Bits (Bit B and Bit A in  
Table 10) of every transmission. These bits are located in either the Extended Link Layer  
(see 5.2.2.2) or the Configuration Field (security mode 0 and 5 only) (see 7.2.4.2 and  
7.2.4.3). The OMS end-device initiates periodical transmissions. If the gateway wants to  
transmit a message to an OMS end-device, it checks the Link Control Bits whether the OMS  
end-device is accessible.  
25  
30  
OMS GROUP  
44/143  
       
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Table 10 Accessibility of an OMS end-device  
Bit A Accessibility of a device  
Bit B  
0
0
OMS end-device provides no access windows (unidirectional OMS end-device)  
Device supports bidirectional access according to OMS in general, but there is no  
access window after this transmission (e.g. temporarily no access in order to keep  
duty cycle limits or to limit energy consumption)  
0
1
Device provides a short access window according to OMS only immediately after  
this transmission (e.g. battery-operated meter)  
1
1
0
1
Device provides unlimited access according to OMS at least until the next  
transmission (e.g. mains powered devices)  
Unidirectional OMS end-devices (Mode C1) are never accessible. Therefore, unidirectional  
actuators are not allowed.  
Mains powered OMS end-devices may provide an unlimited access and the gateway may send  
a command or a request at any time.  
5
The communication partner (e.g., gateway, repeater or service tool) operating in Mode C2  
shall also apply the bits B and A according the Table 10.  
Battery operated bidirectional devices are very restricted in their power consumption. Typically,  
they will provide a short access window only immediately after a transmission. The gateway or  
any other communication device (as master) may initiate communication to the OMS end-  
device (as a slave) during this timeslot. The timing for Mode C shall in accordance with  
[EN 13757-4:2019], clause 9. For Mode C2 the standard defines two response delays: tRO and  
tRO_slow, which are selected by the Response Delay Subfield (D-field) in the communication  
control field of the extended link layer (refer to 12.2.2 in [EN 13757-4:2019]). The stationary  
gateway shall always select D = 0. The OMS end-device may start the communication with  
any value of subfield D.  
10  
15  
The response delay tRO respectively tRO_slow shall be calculated from the end of the OMS end-  
device transmission to the start of the gateway transmission. The transmission of the first chip  
(bit) of the preamble shall start before the maximum delay of tRO respectively tRO_slow expires  
and the OMS end-device shall then receive the transmission from the gateway or another  
device correctly.  
20  
OMS GROUP  
45/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Figure 17 Access timing of an OMS end-device with short access windows (Mode C2  
example)  
Figure 17 shows examples for both correct and wrong access timing to an OMS end-device  
device. The start of the minimum preamble according to [EN 13757-4:2019] shall fall within the  
minimum reception window of the receiver.  
5
4.3.3.2 Access timing for OMS-LPWAN  
For OMS LPWAN the Link Control Bits are located in the MElements of the MAC-Layer and  
are called Downlink accessibility (see Annex Q, Q.3.5). The OMS end-device initiates  
periodical transmissions. The OMS end-device is typically battery operated and can provide  
(one or several) short reception windows after a transmission. If the gateway wants to transmit  
a message to an OMS end-device, it checks the access options in the MElements-field,  
whether the OMS end-device is accessible and at which time. OMS LPWAN supports several  
access options with different delays for the response time (see Annex Q, Q.2.4.6 and Q.2.5.6).  
10  
15  
The OMS LPWAN also support special access optionvalues for unidirectional OMS end-  
devices (with no access windows) and for permanent access applicable for mains powered  
OMS end-devices.  
Further details are provided in Annex Q.  
4.3.3.3 Frequent Access Cycle  
Bidirectional OMS end-devices operating in Mode C shall support the Frequent Access Cycle  
as defined in [EN 13757-4:2019], 12.6.3.3.  
20  
Bidirectional OMS end-devices using OMS LPWAN support a special downlink communication  
session (see Annex Q, Q.3.3.5) to resume an unintended interrupt of a bidirectional  
communication session.  
OMS GROUP  
46/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
4.3.4 Transmissions Limits and Transmission Credits  
An OMS end-device has a nominal transmission interval (refer to 4.3.2.1 and [EN 13757-  
4:2019], 3.12). This results in a nominal number of transmissions (transmitted datagrams) per  
day. Bidirectional devices offer the possibility to request/send additional transmissions from/to  
the OMS end-device. The number of additional transmissions is controlled by the gateway.  
5
Battery powered devices are limited in their power consumption. Mains and battery powered  
devices are limited by the duty cycle. For that reason, it may happen that the OMS end-device  
has to stop communication, if the gateway or another communication unit sends too many  
commands or requests. To handle this issue every bidirectional OMS end-device needs to  
manage additional radio transmissions in terms of power consumption and duty cycle.  
10  
In addition to its unidirectional transmission scheme (see 4.3.2), a bidirectional OMS end-  
device shall provide a minimum of bidirectional communication capability. This is managed by  
so-called credits. The number of credits per message type is given in Table 11.  
Table 11 Credits per datagram  
Messages for bidirectional communication  
Credits per datagram  
b
Receive a SND-UD, SND-UD2  
2
1
1
5
1
0
1
b
Receive a REQ-UD1, REQ-UD2, SND-NKE, CNF-IR  
Receive a pure OMS LPWAN MAC layer message c  
b
Transmit a RSP-UD  
b
Transmit an ACK, NACK  
Transmit a SND-NR, ACC-NR, ACC-DMD, SND-IR a, b  
Transmit a pure OMS LPWAN MAC layer message c  
a
The transmission of these message types is not initiated by the gateway and has not to be  
considered as credits for a bidirectional communication. However, it needs to be considered in the  
power budget calculation for unidirectional communication, which is not in the scope of the credit  
handling specified in this subclause.  
Message types according to 5.2.3  
According to Annex Q  
b
c
NOTE: The credits are intentionally not reflecting the exact energy consumption of different radio  
technologies but are designed for a harmonized usage of the interface in a gateway or backend.  
15  
The OMS end-device shall manage a credit counter that is decremented by the given number  
of credits whenever the OMS end-device transmits or receives a datagram with its own address  
(see 3.1). The OED shall treat a message with unknown C-Field (message type unclear) like  
a SND-UD.  
NOTE 1: To save credits the gateway needs to terminate the session (see 5.2.6).  
20  
25  
30  
The credit counter shall be decremented before sending a datagram. If the credit counter  
becomes less than zero, it shall be set to zero. In case the credit counter becomes zero or the  
duty cycle limit exceeds, the OMS end-device is not able to receive further datagrams and  
shall mark this state by the Link Control Bits (see Table 10 for Mode C and Annex Q, Q.3.5.1.1,  
for OMS LPWAN) of this last datagram and every following spontaneous transmitted  
datagrams. During this period a gateway has no access to the OMS end-device. As soon as  
bidirectional communication is available again, the OMS end-device shall mark this  
accessibility by the Link Control Bits in the next transmissions. The OMS end-device shall  
enable bidirectional communication again at least after the maximum access opportunity delay  
of Table 12. The delay is measured from the first transmission without access to the first  
transmission with access opportunity.  
OMS GROUP  
47/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Table 12 Maximum access opportunity delay  
Radio mode  
Mode C  
Delay in hours  
12  
24  
48  
72  
UL-B4  
UL-B1...B3  
UL-S1…S3  
If an OMS end-device runs into the limit of its duty cycle, it will omit sending any asynchronous  
datagram (see 4.3.2.1). The usage of duty cycle for unidirectional transmissions shall allow a  
minimum number of credits as defined in Table 13 for bidirectional communication.  
An OMS end-device shall increase the credit counter at least as defined in Table 13.  
5
Table 13 Minimum credits per radio mode  
Minimum  
available  
Minimum  
credit  
Radio mode  
credits within  
duty cycle  
per 2 hours  
counter  
increase  
per 2 hours  
Mode C  
240  
240  
120  
120  
10  
5
UL-B4  
UL-B1...B3  
UL-S1…S3  
2
1
The OMS end-device shall accumulate unused credits at least up to 4000 credits. It may  
accumulate more.  
10  
15  
20  
The OMS end-device may interrupt the communication after having used 240 credits within 12  
hours, even if the credit counter > 0 or the duty cycle limits are not exceeded. The OMS end-  
device shall enable bidirectional communication again not later than defined in Table 12 after  
the first transmission without access.  
NOTE 2: The OMS end-device can apply this rule to protect itself against surplus usage of  
credits.  
An OMS end-device that supports a software update via radio (see Annex M.2.6) shall provide  
sufficient battery power for one or several software updates during its lifetime. The number of  
possible firmware updates shall be declared in the data sheet. The power budget for this use  
case must be assigned in addition to the “regular” bidirectional communications as described  
above.  
NOTE 3: If the operator performs more firmware updates than indicated in the data sheet, the  
lifetime of the device may be reduced.  
Once the firmware update has started, it shall not be interrupted due to the credit management  
of a bidirectional communication as described above. The firmware transfer procedure is  
started after the reception of a “Synchronise command” or “Transfer command” and is finished  
after the reception of a “Validate command” or “Terminate command” (see [EN 13757-3:2018],  
Annex I).  
25  
30  
NOTE 4: The activation of the new firmware may be some time after the firmware transfer. For  
that reason, the activation command is not considered a part of the firmware transfer  
procedure.  
If an OMS end-device needs to limit the number of communications on another interface (e.g.  
optical interface), it shall apply an additional power budget management, which is independent  
of the one for the radio interface.  
OMS GROUP  
48/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
5 Link Layer  
5.1 Wired Communication (Wired M-Bus)  
The Link Layer is fully described in [EN 13757-2:2018] and Annex P. The requirements for the  
addressing of wired M-Bus devices are described in subclause 3.1.2 of [EN 13757-2:2018].  
Wired M-Bus devices shall support datagrams with an L-Field 255.  
5
The Link Layer itself does not support multi-datagram messages. Functions requiring more  
data than the maximum length of a datagram may handle a fragmentation of long messages  
via the Authentication and Fragmentation Layer (see clause 6).  
The Annex N of this specification contains examples of wired M-Bus-datagrams.  
5.2 Wireless Communication (Wireless M-Bus)  
5.2.1 General  
10  
The Link Layer applies different frame formats depending on the mode. The Data Link Layer  
with Frame Format A as described in [EN 13757-4:2019] shall be used for wireless  
communication in Mode C. For wireless communication in OMS LPWAN, the Link Layer with  
Frame Format C (see 5.2.3) shall be used instead.  
15  
20  
25  
After the Data Link Layer, a CI-Field introducing structure and length of the next layer follows.  
Such a next layer can be the Authentication and Fragmentation Layer, a Transport Layer (with  
or without Application protocol) or in Frame Format A the Extended Link Layer (see 5.2.2.2).  
Link Layer encryption (provided by the ELL) shall not be applied to any of the frame formats.  
The requirements to the addressing of wireless M-Bus devices are described in subclause  
The Link Layer itself does not support multi-datagram messages. Functions requiring more  
data than the maximum length of a datagram shall handle a fragmentation of long messages  
via the Authentication and Fragmentation Layer (see clause 6).  
The Annex C of the [EN 13757-4:2019] contains datagram examples from the application data  
down to a bit stream. See also Annex N of this specification for examples of different message  
types. For datagram examples in Frame Format C, see Annex Q, Q.K.  
5.2.2 Frame Format A  
5.2.2.1 Data Link Layer  
30  
In Frame Format A, the Data Link Layer as described in [EN 13757-4:2019] shall be used. It  
shall be used in case of the wireless M-Bus Mode C and has a fixed length of 10 bytes (without  
CRC). It includes the datagram length (L-Field) (see 5.2.2.1.1), the C-Field (see 5.2.4) and the  
transmitter address (Link Layer Address). Integrity validation is done in blocks.  
35  
5.2.2.1.1 L-Field (Datagram-Length)  
The L-Field shall be according to [EN 13757-4:2019], 12.5.3.  
A bidirectional OMS end-device shall be able to receive datagrams with an L-Field 155.  
OMS GROUP  
49/143  
           
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
OMS end-devices providing Security profile C (see Table 43) or a Software update over the  
air shall support datagrams with an L-Field 255.  
5.2.2.2 Extended Link Layer  
5.2.2.2.1 General  
5
The Extended Link Layer (ELL) is defined in [EN 13757-4:2019] as an extension of the regular  
Link Layer. The Extended Link Layer shall be applied for wireless M-Bus only.  
5.2.2.2.2 Structure of the Extended Link Layer (ELL)  
There is a short and long Extended Link Layer. The long ELL provides an additional address  
field (see 3.1.3 and 3.1.5).  
10  
NOTE: The [EN 13757-4:2019] supports additional types of Extended Link Layers, which are  
not supported by the OMS.  
CI =  
8Ch  
CC  
ACC  
Figure 18 Short ELL without receiver address  
CI =  
8Eh  
Ident.  
no  
CC  
ACC Manuf.  
Ver.  
Dev.  
15  
Figure 19 Long ELL with receiver address  
Legend:  
CC  
Communication Control Field (see 5.2.2.2.3)  
Access number (see 7.2.2.1)  
ACC  
20  
Ident. No  
Manuf.  
Ver.  
Identification Number (part of receiver address)  
Manufacturer ID (part of receiver address)  
Version (part of receiver address)  
Dev.  
Device Type (part of receiver address)  
OMS GROUP  
50/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
5.2.2.2.3 The Communication Control Field (CC)  
The Communication control field uses the structure as shown in Table 14.  
Table 14 Definition of the Communication Control Field (CC)  
B
D
S
H
0
A
R
0
The link control bits B, A, S, R, H are also present in the Configuration Field, if security mode  
0 or 5 is selected (see 7.2.4.2 and 7.2.4.3). In the case that both the CC-Field and the  
Configuration Field in the datagram exist, only the link control bits of the CC-Field shall be  
applied and the link control bits of the Configuration Field shall be ignored.  
5
10  
15  
The bit S shall be used as described in subclause 4.3.2.1.  
The bits B and A shall be used as described in subclause 4.3.3.1.  
The bit D shall be used as described in subclause 4.3.3.1.  
The bit H is used as a Hop Counter to indicate a repeated transmission. The OMS end-device,  
or gateway shall always transmit bit H = 0b. The bit R is reserved for use in repeated  
messages. The OMS end-device shall always transmit bit R = 0b. An OMS end-device may  
ignore a received bit R.  
5.2.2.2.4 Condition to Apply the Extended Link Layer  
The Extended Link Layer shall always be applied for mode C message types. There is one  
exception due to downward compatibility to former OMS specifications. A unidirectional OMS  
end-device that only uses Security Mode 5 (and 0) can omit the ELL for all applicable message  
types (SND-NR; SND-IR or ACC-NR). A mixture of using and not using the ELL is not allowed.  
20  
25  
NOTE: Without using the ELL it is not possible to transmit new data with asynchronous  
transmissions (see 7.2.2.1).  
The usage of the ELL may also be applied for security mode 5 in the case of an OMS end-  
device with internal encryption function and an external RF-Adapter. Both functions, the  
security mode 5 and the generation of synchronous transmissions, use and increment the  
Access number. For that reason, two Access Numbers are necessary.  
Typically, the usage of the short ELL is sufficient. Special cases that require the long ELL are  
described in subclause 3.1.3.3.  
5.2.3 Frame Format C  
OMS LPWAN applies the Link Layer with Medium Access Control (MAC) and Logical Link  
Control (LLC) sublayers of flexible length. The LLC always applies the Frame Format C as  
described in Annex Q, Q.4. The MAC layer shall be applied according to Annex Q, Q.3.  
30  
OMS GROUP  
51/143  
       
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
5.2.4 Supported C-Fields  
The C-Field is used to declare the message types. It is in conformance with the unbalanced  
C-Fields of [EN 60870-5-2].  
There are different message types for data exchange:  
5
Spontaneous messages without reply  
Commands from master to slave with acknowledge  
Data requests with response from slave to master  
Commands from master to slave with an immediate response  
Special messages for installation or alarm  
10  
The message type is indicated by the C-Field.  
The following C-Fields may be generated by the master (gateway or other communication  
device) and shall be accepted by the slave (OMS end-device).  
Table 15 C-Fields of master (gateway or other communication device)  
Message  
types of  
master  
C-Fields  
(hex)  
Explanation  
Message types of  
responding slave  
Link reset after communication;  
Also signals that after reception of an installation  
datagram it is capable to receive this OMS end-  
device  
SND-NKE  
40h  
-
Send command with subsequent response (Send  
User Data - 2nd message type)  
SND-UD2 b 43h  
RSP-UD, NACK  
SND-UD a  
53h, 73h  
Send command (Send User Data)  
ACK, NACK  
ACK, RSP-UD  
RSP-UD  
-
REQ-UD1 a 5Ah, 7Ah  
REQ-UD2 a 5Bh, 7Bh  
Alarm request, (Request User Data Class1)  
Data request (Request User Data Class2)  
Acknowledge to the reception of the ACC-DMD  
ACK  
00h  
06h  
Confirms the successful registration (installation) of  
OMS end-device into this gateway  
CNF-IR  
-
a
The use of bits FCB, FCV should be in accordance with [EN 60870-5-2] 5  
The SND-UD2 shall not be used for fragmented messages.  
b
Only the message type SND-UD and SND-UD2 can be applied to transport application data to  
an OMS end-device.  
15  
The OMS end-device may send spontaneously or as a reaction to a gateway-datagram the  
following message types:  
Table 16 C-Fields of slave (OMS end-device)  
Message  
types of  
slaves  
C-Fields  
(hex)  
Explanation  
Message types of  
responding master  
Send spontaneous/periodical application data  
without request (Send/No Reply)  
SND-NR b  
44h  
46h  
-
Send manually initiated installation data  
(Send Installation Request)  
CNF-IR,  
SND-IR  
SND-NKE d  
5
The Master is requested to apply FCB accordingly. The slave will ignore FCB. It uses the Access  
number only for the identification of an old/new message (see 7.2.2.1).  
OMS GROUP  
52/143  
       
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Message  
types of  
slaves  
C-Fields  
(hex)  
Explanation  
Message types of  
responding master  
Contains no data signals an empty transmission or  
provides the opportunity to access the bidirectional  
OMS end-device between two transmissions of  
application data.  
ACC-NR  
ACC-DMD  
ACK a  
47h  
48h  
-
Access demand to master in order to request new  
important application data (alerts)  
ACK  
-
Acknowledge the reception of a SND-UD  
(acknowledgement of transmission only);  
It shall also be used as a response to an REQ-UD1,  
when no alert happened  
00h, 10h,  
20h, 30h  
Replace an ACK in the case of a persistent Link  
Layer error:  
01h, 11h,  
21h, 31h  
NACK c  
OMS end-device reception buffer overflow  
Master datagram with invalid or unknown C  
field  
-
-
08h, 18h,  
28h, 38h  
Response of application data after a request from  
master (response of user data)  
RSP-UD a  
a
The use of bits ACD and DFC shall be in accordance with [EN 60870-5-2]  
b
c
The SND-NR shall be used in wireless M-Bus only and not for fragmented messages.  
NACK datagram shall not contain any error codes. A NACK datagram shall only be sent if the  
check of the CRC-tested destination address of the received message has been passed.  
NOTE: A CRC-error is not a persistent Link Layer error.  
SND-NKE is in this case not a direct response to the OMS end-device but an information to third  
party like a service tool to signal an available radio link  
d
Only message types RSP-UD and SND-NR can be applied to transport application data from  
an OMS end-device to the gateway. SND-IR should be applied to transport application data  
for installation and management purposes only. If an OMS end-device does not support alarm  
functions it shall acknowledge a REQ-UD1 with an ACK. Otherwise it shall react according to  
[EN 13757-3:2018], Annex D.  
5
Uni- and bidirectional OMS end-devices shall support the message type SND-NR. Optionally  
SND-IR (for the support of a tool-less installation mode for gateways without external  
installation support) and ACC-NR (see 4.3.2.1) may be supported by the OMS end-device.  
The slave shall reply to every datagram of the master with an expected response, according  
to Table 15 independently of whether this datagram was already received earlier (see 7.2.2).  
Exceptions to this rule are described in subclauses 4.3.3 and 4.3.4. The timing and interaction  
between different message types are shown in Annex L.  
10  
OMS GROUP  
53/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
5.2.5 Repeater for the Wireless Communication  
5.2.5.1 General  
If a direct wireless transmission between an OMS end-device and a gateway is not possible,  
a single intermediate repeater might be used. Such a repeater shall be able to work without  
complex installation procedures and without routing capability. For a common device  
management, a repeater shall send datagrams with its own address to provide device  
management data like status. A repeater conforms to general rules like every OMS end-device.  
The repeater shall send this data periodically (see Table 8). It may optionally send installation  
datagrams (with C = 46h) within given time limits (see 4.3.2).  
5
10  
A repeater may be a dedicated device or a function integrated into an OMS end-device or a  
gateway. An integrated repeater should use the address of the hosted OMS end-device or the  
gateway. Both integrated and dedicated repeaters shall apply the Device Type unidirectional  
repeater” or “bidirectional repeater” (Table 3) for the transmission of repeater management  
data.  
15  
20  
It will be distinguished between:  
Unidirectional repeaters (repeat datagrams from the OMS end-device upward to the  
gateway only)  
Bidirectional repeaters (repeat datagrams in both directions; from the OMS end-device  
upwards to the gateway, and from the gateway downwards to the addressed OMS end-  
device)  
5.2.5.2 Unidirectional Repeater  
The unidirectional repeater repeats only datagrams with C-Fields C = 46h or C = 44h. All other  
datagrams shall be ignored.  
It just retransmits (with some delay) a received Open Metering System compatible datagram  
only in case of Hop Counter Bit = 0 and Repeated Access Bit = 0. The Hop Counter Bit (bit H)  
and Repeated Access Bit (bit R) are placed either in the CC-Field of the Extended Link-Layer  
(see 5.2.2.2.3 and 5.2.2.2.4) or in the Configuration Field in the Transport Layer (see 7.2.4.2  
and 7.2.4.3). In OMS LPWAN, the Hop Counter Bit is placed in the LC[1] field of Frame Format  
C (see Annex Q, Q.4.2.2) instead of the ELL. The repeater shall increment the Hop Counter  
Bit to 1 before the retransmission, what requires the recalculation of the CRC value for the  
second block. Datagrams that do not provide a Hop Counter Bit shall be ignored.  
25  
30  
The retransmission should be randomly delayed for at least 5 seconds and no longer than  
25 seconds after reception time. Due to this delay it is not possible to calculate accurately the  
actual consumption (power, flow) based on the difference of the index values of subsequent  
datagrams. Also, the transfer of the OMS end-device time will not be accurate.  
35  
40  
If the repeater receives an installation datagram (with C = 46h) with a Hop Counter = 0 it shall  
additionally generate a SND-NKE message to confirm the ability of receiving this OMS end-  
device to an optional installation service tool. This message shall be generated with a reaction  
delay between 2 and 5 seconds after retransmission of the OMS end-device message. The  
installation procedure with repeater is shown in Annex L.  
Note that the repeater itself is responsible for staying within duty cycle limits and off time limits  
in any case.  
5.2.5.3 Bidirectional Repeater  
A fully functional bidirectional repeater will be defined in a separate volume of the OMS  
specification.  
45  
OMS GROUP  
54/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
5.2.6 Rules for the Gateway  
If the gateway receives an installation datagram with C = 46h and with a Hop Counter = 0 it  
shall generate a SND-NKE to confirm the ability to receive this OMS end-device to an optional  
installation service tool. This message shall be generated within a random delay between min.  
5 and max. 25 seconds after the direct reception of an OMS end-device installation datagram.  
In addition, it may generate a CNF-IR message to the OMS end-device or an optional  
installation service tool to signal its assignment to this gateway.  
5
10  
15  
20  
In case of an erroneous multiple assignment of one OMS end-device to several gateways,  
collisions may happen when more than one gateway accesses an OMS end-device. To solve  
this failure every gateway shall support a collision avoidance mechanism as defined in Annex  
I. This mechanism describes a random-access taking effect after the second unsuccessful  
access attempt to an OMS end-device.  
If the gateway finishes a communication session with a bidirectional OMS end-device in radio  
Mode C it shall apply a SND-NKE message to stop the Frequent Access Cycle (see 4.3.3.3)  
of the OMS end-device. In OMS LPWAN, OMS end devices don’t apply the Frequent Access  
Cycle. In this case, the gateway shall finish the communication session with a set Session  
Control bit (SC) in MElement_DA in the last downlink frame (see Annex Q, Q.3.3.5).  
The gateway shall provide a clock synchronisation service (see 8.7), unless otherwise  
specified in Annex E. In OMS LPWAN, the MAC layer provides a service for clock management  
(see Annex Q, Q.3.7.2).  
The gateway shall support datagrams with maximum length (L-Field 255).  
OMS GROUP  
55/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
6 Authentication and Fragmentation Layer  
6.1 General  
This section specifies rules for the usage of the Authentication and Fragmentation Layer (AFL)  
as specified in [EN 13757-7:2018, clause 6] in combination with the other layers and security  
modes used in OMS.  
5
6.2 Rules for Specific AFL Fields  
6.2.1 AT-Subfield of AFL.MCL  
OMS end-devices and gateways shall use the value 5 for the AT-subfield (AES-CMAC-128,  
8 bytes).  
10  
Gateways should also support the values 6 and 7 for the AT-subfield (AES-CMAC-128, 12 and  
16 bytes) to be future-proof.  
6.2.2 AFL.KI  
OMS end-devices shall support an internal flag, called KI-Flag, to control the presence of the  
KI-Field. The KI-Flag is cleared by default. If a gateway or any other communication partner  
applies AFL-Key Information Field (AFL.KI) in SND-UD or SND-UD2, then the OMS end-  
device shall set the KI-Flag. Otherwise, it shall clear the KI-Flag. The AFL.KI shall be present  
in RSP-UD as long as the KI-Flag is set. In case of a fragmented response and an enabled KI-  
Flag, the AFL.KI field shall be present in the first fragment. It should not be present in any  
following fragments of the same message.  
15  
20  
6.2.3 AFL.MCR  
The AFL.MCR shall be present in messages from/to OMS end-devices that are protected by  
Security profile B. It is also required for selected messages of Security profile C (see Annex  
F). See 9.2.5 for details on the requirements for the message counter.  
6.2.4 AFL.MAC  
25  
If the MAC-Field is used, the AFL.MAC field shall only be present in the last fragment of a  
message, i.e. the entire message shall be authenticated.  
NOTE: OMS supports only the authentication of the complete message. Therefore, the MAC  
is only present in the last fragment.  
6.2.5 AFL.ML  
30  
The message length shall be limited to 16 kbytes.  
For unfragmented messages, the AFL.ML shall not be used.  
OMS GROUP  
56/143  
               
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
6.3 Conditions to Apply an AFL  
The AFL shall be applied  
In each datagram of a fragmented message (SND-UD, RSP-UD)  
In message types with application data (SND-NR, SND-UD, SND-UD2, SND-IR, RSP-  
UD) using Security profile B (see 9.1)  
5
In each RSP-UD message, when KI-Flag is set (see 6.2.2)  
In selected messages using Security profile C (see 9.1) with CMAC (see Annex F,  
F.3.4)  
If the AFL is used, the rules specified in 6.2 shall apply.  
10  
If the required AFL is missing or wrong in SND-UDx messages the OMS end-device shall  
provide an application error (see 8.8).  
OMS GROUP  
57/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
7 Transport Layer  
7.1 Overview  
The Transport Layer always has a fixed frame structure as described in [EN 13757-7:2018]. It  
may transport either the OMS end-device Application Protocol according to [EN 13757-3:2018]  
(M-Bus), or alternatively [EN 13757-1:2014] (DLMS/COSEM communication primarily used by  
electricity meters). Note that the CI-Field as the first byte of the Transport Layer distinguishes  
between these Application Protocol types and the frame structure. A gateway or a consumer  
display shall be able to handle all Application Protocol types at least to the extent that it can  
extract the values required for its function or application from the message. This specification  
part covers mainly the M-Bus variant.  
5
10  
NOTE: The gateway or the display needs to be able to parse any applied (M-Bus or COSEM  
or SML) Application Protocol into separate data points. However, it is sufficient to “understand”  
i.e. decode only the required values stated in clause 8.  
7.2 Common Part for All Transport Layers  
15  
20  
7.2.1 General Structure of the Transport Layer  
The frame format of the Transport Layer is the same for all Application Protocols. The  
Transport Layer starts with a CI-Field (see 2.2), which indicates the main message function  
and the type of coding (i.e. the Application Protocol) used for the rest of the message. After  
the CI-Field a fixed sequence of bytes follows, which is called TPL-header. There are three  
types of TPL-headers.  
The TPL-header structures are:  
No TPL-header:  
This TPL-header type is used on the wired M-Bus for unencrypted messages. The next  
byte after the CI-Field is the first byte of the selected Application Protocol.  
Short TPL-header:  
The Short TPL-header is used only for wireless M-Bus. If the message contains such  
a “short” TPL-header, the OMS end-device identification is taken from the Link Layer  
25  
30  
Long TPL-header:  
The Long TPL-header is used for both wired and wireless M-Bus. If the message  
contains such a “long” TPL-header, this TPL-header always contains (independent of  
transmission direction) the OMS end-device identification (see 3.1.3.4 and 3.1.4.4).  
The long TPL-header enables encrypted messages on the wired M-Bus.  
Every Short/Long TPL-header for wireless M-Bus contains:  
35  
Access number  
status byte  
Configuration Field  
Depending on the selected security mode in the Configuration Field, additional bytes (like  
Configuration Field Extension or Decryption-Verification) may follow before the Application  
Protocol starts. The structures of the Transport and Application Layer is pictured in Annex D.  
Table 1 in subclause 2.2 lists all supported CI-Fields and the related TPL-header types.  
40  
OMS GROUP  
58/143  
       
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
7.2.2 Access Number  
7.2.2.1 Access Number for Wireless M-Bus  
The Access Number together with the transmitter address is used to identify a datagram. It will  
be distinguished between:  
5
OMS end-device Access Number  
Gateway Access Number  
The OMS end-device Access Number is generated by the OMS end-device. It shall be  
incremented by 1 (and only 1) with every synchronous transmission (see 4.3.2.1).  
Asynchronous transmissions shall always apply the OMS end-device Access Number of the  
last synchronous transmission. The OMS end-device Access Number shall be applied to SND-  
NR, SND-IR, ACC-NR and ACC-DMD datagrams. If a gateway accepts an ACC-DMD or a  
SND-IR from an OMS end-device, it has to send an acknowledgement (ACK or CNF-IR) using  
the received OMS end-device Access Number. The received Gateway Access Number has no  
impact on the stored OMS end-device Access Number of the OMS end-device. After power-  
up of the OMS end-device the value of the OMS end-device Access Number shall be set to a  
randomized initial value from 0 to 255. The OMS end-device Access Number shall not be  
resettable.  
10  
15  
An access number in the link layer (LL-ACC) can either be provided in Frame Format C (LLC-  
ACC) or in the Extended Link Layer (ELL-ACC) in case of Frame Format A. If an LL-ACC  
exists, it shall be used for the synchronous transmission and Link acknowledgement. Each  
datagram can be identified by the LL-ACC. In case the LL-ACC does not exist (i.e. for Security  
Profile A) the TPL-ACC shall be used for synchronous transmission.  
20  
The additional Access Number of the Transport Layer (TPL-ACC) may differ from the LL-ACC.  
This TPL-ACC shall be used to indicate a new or old message content. Each message can be  
identified by the TPL-ACC. The (first) response (RSP-UD) of a (fragmented) message shall  
contain the TPL-ACC of the concerning request (REQ-UD2) and the (last) acknowledgement  
(ACK) of a (fragmented) message shall contain the TPL-Access Number of the concerning  
command (SND-UD). Other acknowledgement datagrams of a fragmented message may  
contain a Transport Layer (with the TPL-ACC) e.g. to provide an application error bit in the  
status byte.  
25  
30  
The relation of the Access Number terms is shown in Figure 20.  
Figure 20 Access Number  
The Gateway Access Number is generated by the gateway. It may be selected without any  
restrictions. However, the gateway shall not use the same Gateway Access Number for a new  
35  
OMS GROUP  
59/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
datagram to the same OMS end-device again within 300 seconds. Each time the Gateway  
Access Number is changed, the gateway should alternate the FCB (see 5.2.4).  
The OMS end-device shall not expect any specific order of Gateway Access Numbers in  
datagrams received from the gateway. It shall only distinguish between a new and an old  
datagram. The last received Gateway Access Number marks an old datagram. All other  
Gateway Access Numbers different from the last received one will be handled as the new  
Gateway Access Number. The content of the FCB (see 5.2.4) shall be ignored. When the OMS  
end-device finishes the Frequent Access Cycle (see 4.3.3) or closes the downlink  
communication session (see Q.3.3.5), it shall clear the last received Gateway Access Number.  
After that any received Gateway Access Number will be handled as a new one.  
5
10  
If the OMS end-device receives an SND-NKE, SND-UD, SND-UD2, REQ-UD1, or REQ-UD2,  
it shall use the received Gateway Access Number of the LL-ACC for its response or  
acknowledgement. The gateway may recognize an outstanding response or  
acknowledgement by its own Gateway Access Number. Hence the OMS end-device repeats  
the last response or acknowledgement, if the gateway has sent the request or the command  
with the old LL-ACC again. Otherwise, it shall generate a new datagram with the new LL-ACC  
received from the gateway.  
15  
NOTE: These rules to apply the Access number for wireless M-Bus is in accordance with  
[EN 13757-7:2018].  
20  
7.2.2.2 Access Number for Wired M-Bus  
For wired M-Bus the Access Number shall be in accordance with [EN 13757-7:2018], 7.5.5.  
7.2.3 Status Byte  
The status byte shall be applied as defined in [EN 13757-7:2018]. It will be distinguished  
between the OMS end-device status (see [EN 13757-7:2018], 7.5.6) and gateway status (see  
[EN 13757-7:2018], 7.5.7).  
25  
30  
In a 2-way communication, the OMS end-device shall indicate in the status byte its application  
status within an ACK or RSP-UD message. Table 17 provides the three application states  
coded in the lowest two bits of the status byte (according to [EN 13757-7:2018], 7.5.6, Table 15  
Application errors coded with the status field) to reflect the state of the command response  
(see 8.2.5). It also shows the fourth possibility, which is limited to self-initiated messages.  
Table 17 Application error bits in OMS end-device status byte  
Status Status Command  
Usage  
Bit 1  
Bit 0 state  
Shall be used if the last command was processed successfully and  
complete without any issue.  
0
0
No error a, d  
Shall be used as default response as long as no positive or  
negative feedback to the last command has been received from the  
(internal) application.  
Application  
busy b, d  
0
1
1
0
Any  
Shall be used, if a problem was detected in terms of authentication  
check, decryption, interpretation, or execution to the last command.  
The RSP-UD provides an Error Response (see 8.2.5).  
application  
error c, d  
1
1
Abnormal  
condition/  
alarm  
Shall not be used as a reaction to a command.  
It can be used in self-initiate push messages or in normal data  
response states (see 8.2.3).  
OMS GROUP  
60/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Status Status Command  
Bit 1 Bit 0 state  
Usage  
a
b
c
If a "Command Successful" (see 8.2.5) was used the gateway does not need to send a REQ-UD2.  
The gateway should request the “final” status with another REQ-UD2 (using a new TPL-ACC).  
The gateway should send a REQ-UD2 if the bit combination "any application error" is set to read  
back the application error.  
Note that older OMS end-devices may not support these application error bits and always use  
"00b".  
d
Annex L.5 shows a sequence diagram that illustrates the three possible command response  
states.  
The state of the application error bits in status byte shall be updated whenever a new  
application response is generated. Subclause 8.2.5 shows, which events change the  
application response.  
5
NOTE: During the datagram repetition within the FAC (see 4.3.3.3) the status byte will not be  
updated.  
It is recommended, that the Low Power bit is set 15 months before the intended end of  
operation.  
10  
Details about other error conditions like "permanent error" may be provided in an Application  
Protocol (see 8.4.5.2).  
7.2.4 Configuration Field  
7.2.4.1 General  
The Configuration Field shall be used as specified in [EN 13757-7:2018]. It declares the  
method of data encryption (security mode) and the length of encrypted data. The security mode  
is a part of the Configuration Field declared by the bits MMMMM. The security mode also  
determines the presence of the Configuration Field Extension and the meaning of all other bits  
15  
20  
NOTE 1: In former OMS-Specifications the Configuration Fields for security modes 7 and 13  
were presented as a 3-byte field. According to [EN 13757-7:2018] the Configuration Field is  
limited to two bytes. Additional bytes are called Configuration Field Extension (CFE) and are  
presented separately. Nevertheless, the byte order in the message is the same.  
Table 18 shows the general structure of the Configuration Field and the position of the security  
mode.  
25  
Table 18 General definition of the Configuration Field  
X
X
X
M
M
M
M
M
X
X
X
X
X
X
X
X
NOTE 2: In [OMS-S2]. Issue 3.0.1 the applied Mode Field includes only bit 8 to bit 11. Bit 12  
was marked as reserved. From [OMS-S2] Issue 4.0.2 on the Mode Field includes the bits from  
bit 8 to bit 12.  
OMS GROUP  
61/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
For OMS only the following security modes shall apply:  
Security mode 0 (no encryption)  
Security mode 5 (OMS standard for symmetric encryption)  
Security mode 7 (OMS standard for advanced symmetric encryption)  
Security mode 10 (OMS standard for advanced symmetric authenticated-encryption)  
Security mode 13 (OMS standard for asymmetric encryption)  
5
Subclause 9.3 describes the usage of these security modes. The next sub-sections describe  
the structure of the mode specific Configuration Fields.  
7.2.4.2 Configuration Field for Security Mode 0  
10  
The structure of the Configuration Field of Mode 0 is identical to security mode 5 (see  
Table 19). The M and N bits have to be set to 00h to indicate that no encryption is applied. See  
also subclause 9.3.4.  
7.2.4.3 Configuration Field for Security Mode 5  
Security mode 5 is a symmetric encryption method using AES128 with CBC, a special  
initialisation vector, and a persistent key (see 9.3.5).  
15  
Table 19 Definition of the Configuration Field for security mode MMMMM = 5  
B
A
S
M
M
M
M
M
N
N
N
N
C
C
R
H
M is always 05h to mark AES128 with CBC and persistent key.  
N contains the number of encrypted 16-byte blocks for CBC Mode. An N of 1111b specifies  
that partial encryption is disabled and no unencrypted data follows after the encrypted data.  
This enables the possibility to encrypt very large fragmented messages. If N is set to 0000b,  
no encrypted data follows.  
20  
C declares the Content of Message (see 7.2.4.7).  
B, A, S, R, and H are used to control the link (see 7.2.4.8).  
A two-byte sequence 2Fh, 2Fh (decryption verification) shall immediately follow the  
Configuration Field. The Decryption Verification Field is part of the Transport Layer.  
25  
NOTE: The Mode 5 may be used without Extended Link Layer and without Authentication and  
Fragmentation Layer (see 5.2.2.2.4).  
7.2.4.4 Configuration Field for Security Mode 7  
Security mode 7 is a symmetric encryption method using AES128 with CBC and an ephemeral  
key (see 9.3.6). It is possible to identify up to 16 different communication security keys using  
the KeyID.  
30  
OMS GROUP  
62/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
The Configuration Field (CF) to be used for security mode 07h is defined as follows:  
Table 20 Configuration Field for security mode 7  
C
C
0
M
M
M
M
M
N
N
N
N
P
I
I
I
M is always 07h to mark AES128 with CBC and ephemeral key.  
C declares the Content of the Message, I declares the Content Index (see 7.2.4.7).  
P is the padding bit according to [EN 13757-7:2018], 9.4.5.4.  
5
N contains the number of encrypted 16-byte blocks for CBC Mode. An N of 1111b specifies  
that partial encryption is disabled and no unencrypted data follows after the encrypted data.  
This enables the possibility to encrypt very large fragmented messages. If N is set to 0000b,  
no encrypted data follows.  
10  
Security mode 7 requires a Configuration Field Extension according to Table 21.  
Table 21 Configuration Field Extension for security mode 7  
0
0
D
D
K
K
K
K
K selects the KeyID for Encryption and Authentication used in the TPL. Applicable KeyID's are  
defined in 9.1 and 9.2.2.  
D is 01b to mark key derivation function as defined in subclause 9.2.5.  
15  
A two-byte sequence 2Fh, 2Fh (decryption verification) shall immediately follow the  
Configuration Field Extension. The Decryption Verification Field is part of the Transport Layer.  
OMS GROUP  
63/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
7.2.4.5 Configuration Field for Security Mode 10  
Security mode 10 is a symmetric authenticated-encryption method using AES128 with CCM  
and an ephemeral key (see 9.3.6). It is possible to identify up to 16 different communication  
security keys using the KeyID.  
5
The Configuration Field (CF) to be used for security mode 0Ah is defined according to Table  
Table 22 Configuration Field for security mode 10  
C
C
Z
M
M
M
M
M
N
N
N
N
N
N
N
N
M is always 0Ah to mark AES128 with CCM and ephemeral key.  
C declares the Content of the Message (see 7.2.4.7).  
10  
15  
Z is always 1b to declare that TPL contains a message counter (see 9.3.2) with a size of 4  
bytes (acc. to [EN 13757-7:2018], 7.7.8).  
N contains the number of encrypted bytes for CCM Mode. An N of 11111111b specifies that  
partial encryption is disabled and no unencrypted data follows after the encrypted data. This  
enables the possibility to encrypt very large fragmented messages. If N is set to 00000000b,  
no encrypted data follows.  
Security mode 10 requires a Configuration Field Extension according to Table 23.  
Table 23 Configuration Field Extension for security mode 10  
0b 0b  
I
I
I
I
O
O
0b  
V
D
D
K
K
K
K
K selects the KeyID for the authenticated-encryption used in the TPL. Applicable KeyID's are  
defined in 9.1 and 9.2.2.  
OMS GROUP  
64/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
D is always 01b to mark key derivation function as defined in subclause 9.2.5.  
NOTE 1: The Security Mode 10 applies only one derived key per direction, which is always the  
Kenc (DC=00h) for the authenticated encryption from the OMS end-device and Lenc (DC=10h)  
for the authenticated encryption from the gateway.  
5
O is always 01b to mark an 8 byte Authentication Tag at the end of the message (acc. to  
[EN 13757-7:2018], 7.7.8).  
If V is 1b then the field KeyVersion (KV) is present (1 byte, acc. to [EN 13757-7:2018], 7.7.8).  
Otherwise, V is 0b. OMS end-devices shall support an internal flag, called KI-Flag according  
to section 6.2.2. The V-flag of the Configuration Field Extension of mode 10 is set under the  
same conditions as this KI-flag. See section 6.2.2 for the rules for setting the KI-flag.  
10  
The use of KeyID, KeyVersion and Message counter for the TPL-security shall apply the  
corresponding fields from the TPL. If the AFL contains similar information, these AFL-fields  
shall be ignored.  
I declares the Content Index of the Message (see 7.2.4.7)  
15  
NOTE 2: The Authentication Tag of the mode 10 is located in the TPL-Trailer of the Message  
after the APL. (see [EN 13757-7:2018], Table 20)  
7.2.4.6 Configuration Field for Security Mode 13  
Security mode 13 is an asymmetric encryption method using TLS (see Annex F).  
Table 24 Configuration Field for security mode 13  
C
C
0
M
M
M
M
M
N
N
N
N
N
N
N
N
20  
M is always 0Dh (13 decimal) to declare an Encryption with TLS  
NOTE 1: The applied TLS-Version can be retrieved from the TLS-Header.  
C declares the Content of message (see 7.2.4.7).  
N contains the number of encrypted bytes. It indicates the number of bytes following the  
Configuration Field, which are covered by the Protocol indicated by Protocol type (TLS). N is  
limited to 255.  
25  
NOTE 2: For larger sizes the exact number of bytes (minus the TLS header size 5 Bytes) can  
be found in the 4th and 5th Byte of the TLS header.  
Security mode 13 requires a Configuration Field Extension according to Table 25.  
OMS GROUP  
65/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Table 25 Configuration Field Extension for security mode 13  
0
0
0
0
P
P
P
P
P defines the Protocol Type (see Annex F).  
NOTE 1: No Decryption Verification Field follows the Configuration Field.  
NOTE 2: The usage of the mode 13 on wireless M-Bus requires the application of the Extended  
5
Link Layer.  
7.2.4.7 Content of Message and Content Index  
All security modes provide the bits CC in their Configuration Field that are used to describe the  
content of the message. They are defined in [EN 13757-7:2018], Table 21- Content of meter  
message and Table 22 Content of partner message.  
10  
15  
The identification of message contents is extended by the Content Index bits (IIII). Using those  
bits, a gateway is able to identify and store or filter messages with different content without the  
need to decrypt the application data. The following table shows the intended usage of the  
Content Index bits for an OMS end-device in relation to 8.4.4. Table 26 is valid for a content of  
message (CC = 00b) representing a standard data message.  
NOTE 1: Content Index bits are only provided for Security Profile B and Security Profile D.  
Security profile B is supporting only the 3 least significant bits of the content index.  
Table 26 OMS usage of Content Index bits for CC = 00b  
Content Index [IIII] Contents of the message  
(binary)  
0000  
0001  
Legacy OMS end-device, no further usage of Content Index  
Data for mobile readout (MSO)  
0010  
Data for fixed network readout (MSO)  
Consumer information (CON)  
0011  
0100 ... 0111  
Manufacturer specific usage  
Table 27 is valid for a content of message with CC = 01b representing an additional data  
message.  
20  
NOTE 2: A future issue of [EN 13757-7] will be enhanced with the CC = 01b value.  
Table 27 OMS usage of Content Index bits for CC = 01b  
Content Index [IIII] Contents of the message  
(binary)  
0000 0011  
0100 0111  
1000 1011  
1100 1111  
Additional data for fixed network readout (MSO)  
Reserved for future use  
Additional data for fixed network readout (MSO)  
Reserved for future use  
OMS GROUP  
66/143  
       
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
NOTE 3: Other CC values might have a different interpretation of the IIII bits.  
The expected content for each content index value is defined in 8.4.4. The relation between  
content index and message application is defined in 8.10.  
7.2.4.8 Link Control Bits of the Configuration Field  
5
The Configuration Field of security mode 5 and 0 supports the Link Control Bits B, A, S, R, and  
H. These bits may also be provided by lower layers.  
If these bits do not exist in either ELL, LLC or MAC then  
the bit S shall be used as described in subclause 4.3.2.1  
bits B and A shall be used as described in subclause 4.3.3.1  
bits H and R shall be used as described in subclause 5.2.2.2.3.  
10  
Otherwise, these Link Control Bits in the Configuration Field should be set to zero.  
If these bits exist in the lower layer, the Link Control Bits in the TPL shall be ignored (see  
The subclause 5.2.2.2.4 describes the conditions whether or not an Extended Link Layer exists  
in Mode C. For the usage of the Link Control Bits of OMS LPWAN see Annex Q.  
15  
7.3 Conditions to Apply the Transport Layer  
The Transport Layer is required for message types with application data. Also message types  
without application data use the TPL to provide following services:  
OMS end-device address,  
Access number of the message,  
Reception level of the OMS end-device,  
Status byte (with result of the command execution from last SND-UD)  
20  
OMS GROUP  
67/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
The OMS end-device shall apply the TPL for the message types according to Table 28.  
Table 28 Usage of TPL depending on message type  
Direction  
Message type  
Presence TPL  
wired M-Bus  
Presence TPL  
wireless M-Bus  
SND-NKE  
SND-UD  
SND-UD2  
REQ-UD1  
REQ-UD2  
ACK  
Never  
Always  
Optional a  
Optional a  
Never  
Always b  
Always  
Always  
Never  
Always b  
Always  
Not applicable  
Not applicable  
Not applicable  
Not applicable  
Not applicable  
Not applicable  
Never  
CNF-IR  
SND-NR  
SND-IR  
ACC-NR  
ACC-DMD  
ACK  
Always  
Always  
Always  
Conditional d  
Always  
Always c  
Never  
NACK  
Not applicable  
Always  
RSP-UD  
Always b  
a
In case of encryption the TPL is necessary  
For a fragmented message sequence the TPL shall only be in the first datagram (see 7.2.2.1)  
For a fragmented message sequence the TPL shall be at least in the last ACK (see 7.2.2.1 and  
b
c
d
If S-bit and ACC is not present in the lower layers (ELL or LLC), the TPL shall be provided (see  
OMS GROUP  
68/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
8 Application Protocols  
8.1 Overview  
Possible Application Protocols for OMS end-device application data are:  
M-Bus (see 8.4)  
DLMS (see 8.5)  
SML (see 8.6)  
5
Beside these Application Protocols for OMS end-device data exchange, some more  
Application Protocols for special services exist. These protocols are supported in case the  
conditions of Table 29 apply.  
10  
Table 29 Application protocols  
Name of Application Protocol a  
Condition  
Reference  
Support shall be declared in  
ManDec  
[EN 13757-3:2018],  
Annex D  
Alarm  
Mandatory for bidirectional  
wireless or wired M-Bus  
Mandatory for bidirectional  
wireless or wired M-Bus  
Application Error  
see 8.8  
Application Select  
see 8.7  
Clock Synchronisation  
refer to  
Image transfer  
[EN 13757-3:2018],  
Annex I  
Refer to  
Network Management Protocol  
Security Information Transfer  
Future UC, Annex M  
[EN 13757-4:2019],  
clause 14  
Several use cases of Annex M;  
Security mode 13  
Security Management Protocol  
Security mode 13  
see 8.9  
a
Refer to Table 1 column “Protocol or Service” for respecting CI-Field values  
8.2 Message Types and Their Application Data Content  
8.2.1 Overview  
The applicative content of a message from an OMS end-device depends on the message type  
and the current OMS end-device state. This state is influenced by internal and/or external  
events. This can e.g. be an internal transmission scheme, an external trigger, or a command.  
15  
There are following options to get application data from the OMS end-device  
OMS GROUP  
69/143  
         
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Table 30 Message types and their application data content  
Typical Application  
content  
Installation data  
Trigger event  
Message type  
Reference  
Manually external trigger  
Periodically  
SND-IR a  
SND-NR a  
RSP-UD b  
RSP-UD  
Clause 8.2.2  
Clause 8.2.3  
Clause 8.2.4  
Clause 8.2.5  
Consumption and  
management data  
Alarm information  
REQ-UD1  
SND-UDc+REQ-UD2 or  
SND-UD2  
Any application data or  
command response  
a
Only for wireless M-Bus; wired M-Bus will provide this data with RSP-UD  
Alarm information can also be pushed by SND-NR  
SND-UD is optional and required for a command reply and application select  
b
c
8.2.2 SND-IR  
Figure 21 shows externally triggered push messages. Once the SND-IR message has been  
triggered, it is repeated several times.  
5
Figure 21 States of an externally triggered transmission event  
Table 31 States of a SND-IR  
State  
Explanation  
Reference  
Provides preselected installation data  
according the rules for installation  
messages  
SND-IR Preselected Data  
Clause 4.3.2.4  
Table 32 State change events of a SND-IR  
Event  
Explanation  
Reference  
An external trigger to start the installation  
mode, e.g. a push button  
External trigger  
Clause 4.3.2.4  
Installation messages are repeated several  
times  
Repetition event  
Clause 4.3.2.4  
10  
15  
8.2.3 SND-NR/ACC-NR  
For a SND-NR message there might be two different contents (dynamic and static). The  
dynamic data contains consumption data and other information, which may change frequently.  
The SND-NR with static data contains information for OMS end-device management that either  
never changes (e.g. id of metering point) or for which a rare update cycle is sufficient (e.g.  
changed ownership number). Between the SND-NR transmissions (dynamic or static), also  
ACC-NR messages without application data may be sent. There is no specific initial state. (see  
OMS GROUP  
70/143  
           
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Figure 22 States of a periodical transmission event  
Table 33 States of a SND-NR/ACC-NR  
State  
Explanation  
Reference  
Provides consumption data according to an Clause 4.3.2.2  
SND-NR Dynamic Data  
internal transmission scheme  
Clause 8.4.4  
Provides management data according to an  
internal transmission scheme  
Provides only access to the OMS end-  
device according to an internal transmission Clause 4.3.2.1  
scheme  
SND-NR Static Data  
ACC-NR No Data  
Clause 4.3.2.5  
Table 34 State change events of a SND-NR/ACC-NR  
Explanation  
Event  
Reference  
Transmission event according to a  
transmission scheme  
Periodical transmission event  
Clause 4.3.2  
5
8.2.4 RSP-UD/ACK after REQ-UD1  
In case the OMS end-device supports the alarm protocol it can react with two different  
message types. Otherwise always an ACK shall be provided.  
Figure 23 Alarm response states  
10  
OMS GROUP  
71/143  
         
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Table 35 States of a RSP-UD/ACK after REQ-UD1  
Explanation  
State  
Reference  
[EN 13757-4:2019]  
or [EN 13757-  
2:2018]  
No Alarm  
In case of no alarm an ACK shall be sent  
In case of an alarm the alarm protocol  
should be sent  
[EN 13757-3:2018]  
Annex D  
Alarm  
Table 36 State change events of a RSP-UD after REQ-UD1  
Event  
Explanation  
Reference  
An internal event (manufacturer specific)  
that causes an alarm  
Alarm Event  
With the transmission of the alarm by the  
RSP-UD message, the alarm should be  
cleared. a  
[EN 13757-3:2018],  
Annex D  
Read Alarm  
A manufacturer specific timeout that clears  
the alarm  
The message might stay in the sending buffer to provide repetitions according the transmissions  
rules, e.g. FAC  
Alarm Timeout  
a
8.2.5 RSP-UD after REQ-UD2 or SND-UD2  
Figure 24 shows the applicative response states that define the content of a RSP-UD message  
after a REQ-UD2 or a SND-UD2. It also shows possible state change events. A REQ-UD2  
itself is not a state change event whereas a SND-UD or SND-UD2 will influence the state  
according to the state change event table.  
5
Specific data contents can be requested (e.g. with the Application Select Protocol see 8.10).  
Each command will react with dedicated applicative responses (see Annex B).  
10  
The initial state shall be automatically applied after the power-up, a device reset or after a  
disconnection from the wired M-Bus line as defined in [EN 13757-2:2018], 4.2.2.11.  
OMS GROUP  
72/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Figure 24 Data response states  
Table 37 States of a RSP-UD after REQ-UD2/SND-UD2  
State  
Explanation  
Reference  
Defined by the manufacturer  
Contains mandatory data points  
Contains data according chosen message  
application  
Applicative response to a command as  
defined in Annex M  
Standard Response  
Clause 8.4.4  
Selected Response  
Command Response  
Clause 8.10  
Clause 8.8 and  
[EN 13757-7:2018],  
Annex A.8.8  
Response to a command that caused an  
error e.g. with Application Error protocol  
Error Response  
5
OMS GROUP  
73/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Table 38 State change events of a RSP-UD after REQ-UD2/SND-UD2  
Event  
Explanation  
Reference  
Successfully received and processed  
command; recognisable by the indication of  
“no error” in the TPL status byte (see  
Table 17) of the corresponding response  
(ACK, RSP-UD).  
Command Successful  
Successfully received but not successfully  
processed command; recognisable by the  
indication of “any application error” in the  
TPL status byte (see Table 17) of the  
corresponding response (ACK, RSP-UD).  
Selection of a dedicated message  
application  
Selection of the standard response  
The timeout is 255 seconds and is started  
with the last command reception.  
Clause 8.8 and  
[EN 13757-7:2018],  
Annex A.8.8  
Command Not Successful  
Application Select  
Application Reset  
Command Timeout  
Clause 8.10  
Clause 8.10  
8.3 Resolution and Accuracy of Consumption Data  
An OMS end-device shall be in accordance with Annex C.2 of [CEN/TR 17167:2018].  
If power or flow values are transmitted and the applied averaging interval is smaller than the  
nominal transmission interval, then the data point Averaging Duration should be transmitted  
additionally.  
5
NOTE: The transmission of the Averaging Duration in the static datagram (see 4.3.2.5) will be  
sufficient.  
8.4 M-Bus Application Protocol  
10  
8.4.1 General  
The M-Bus Application Protocol is described in [EN 13757-3:2018]. To ensure interoperability,  
the use of the M-Bus Application Protocol in OMS is restricted by the following additional rules.  
8.4.2 OMS-Data Point List  
The Annex B lists all harmonised M-Bus-Data points in the OMS-Data point list (OMS-DPL).  
This list consists of a VIB-Type List and an M-Bus-Tag Lists.  
15  
The VIB-Type List provides all supported combinations of VIFs and VIFEs applied conforming  
to this specification.  
The M-Bus tag lists provide all M-Bus tags applicable and conforming to this specification. An  
M-Bus-Tag is an abstract presentation of a single M-Bus data point or a set of M-Bus-Data  
points that differ by the scaler (see VIB-Type List of Annex B) or resolution.  
20  
8.4.3 OMS-Gateway  
OMS-Gateways shall support all M-Bus data points listed in the OMS-DPL (see Annex B).  
The standard load profile and the M-Bus compact profile according to [EN 13757-3:2018],  
Annex F shall be supported. See Annex G for examples for the conversion of load profiles to  
single data points.  
25  
OMS GROUP  
74/143  
           
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
M-Bus data points compliant with [EN 13757-3:2018], but not listed in the OMS-DPL, may  
optionally be supported by OMS-Gateways.  
8.4.4 OMS end-device  
OMS end-devices shall provide all M-Bus data points that are marked as mandatory (M) and  
at least one of the data points marked as alternative (Ax) in the OMS-DPL (see Annex B for  
the OMS end-device with the respective Device Type). Those data points are called “obligatory  
data points”. The exact DIB/VIB coding given in the Annex B shall be used. If multiple  
alternatives are provided in one message, all data points shall provide the required accuracy  
and resolution.  
5
10  
15  
If the OMS end-device supports OMS use cases according to Annex M, it shall support the  
conditional data points as specified in Annex B.  
Note that each data point shall be unique within a message. This means it is not allowed to  
provide the same combination of DIB (tariff, subunit, storage number, function code, final DIFE)  
and VIB in several data points. Several data points that differentiate only by the data type  
(INT/BCD), the measurement unit or the resolution are also not allowed.  
Obligatory data points shall be present in the standard response (see 8.2.5).  
NOTE: The standard response can be selected with an application reset [see  
[EN 13757-3:2018], clause 7].  
Wireless devices shall additionally transmit obligatory data points with SND-NR messages  
according to Table 39. The obligatory data points shall be provided respecting the update  
interval maximum of Table 8.  
20  
Table 39 Conditions for obligatory/conditional data points in SND-NR messages  
Security  
Profile  
Content of  
message  
[CC]  
Content Index Synchronous /  
Are  
Origin of  
Field  
[IIII]  
Asynchronous  
[S]  
obligatory/  
conditional  
data points  
required?  
obligatory/  
conditional  
data points  
(binary)  
(binary)  
(binary)  
A, C  
B, D  
A, C  
B, D  
B, D  
B, D  
00  
00  
00  
00  
00  
00  
N/A  
0000 a  
1
Yes  
Yes  
No  
N/A  
1
N/A  
0
0000 a  
0001  
0010  
0
No  
N/A  
0…1  
0…1  
No  
N/A  
Yes  
UC-07  
B, D  
00  
0011  
0…1  
Yes  
B, D  
A, C  
B, D  
B, D  
00  
0100…0111 b  
N/A  
0…1  
0…1  
0…1  
0…1  
0…1  
No  
No  
No  
No  
No  
N/A  
N/A  
N/A  
N/A  
N/A  
10  
10  
0000  
01 c  
01 c  
0000 0011  
1000 1011  
D
a
The combination of (CC = 00b; IIII = 0000b) shall only be transmitted by devices not supporting  
the differentiation of content according to Table 26 (backward compatibility).  
Use this to provide manufacturer specific content without providing obligatory data points.  
These combinations of Content of message and Content Indexes are used to provide additional  
data transmissions for fixed network readout.  
b
c
If an OMS end-device provides additional M-Bus data points marked as optional (O) in the  
OMS-DPL, it shall use the exact DIB/VIB coding given there.  
OMS GROUP  
75/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
OMS end-devices may additionally use the standard load profile or the M-Bus compact profile  
according to [EN 13757-3:2018], Annex F. The underlying single M-Bus data points shall use  
the exact DIB/VIB coding given by the OMS-DPL. See Annex G for examples for the  
conversion of load profiles to single data points.  
5
M-Bus data points that are listed in the OMS-DPL shall not be used in alternative or  
manufacturer specific sense.  
Additional M-Bus data points that are not explicitly listed in the OMS-DPL, but comply with  
[EN 13757-3:2018], may optionally be provided by the OMS end-device. But these additional  
data points shall not be used as replacement for present data points in the OMS-DPL.  
10  
8.4.5 Usage of Specific Data Points  
8.4.5.1 Date, Time and Intervals  
For the averaging time interval of power or flow values the data point “averaging duration”  
(DP2!) shall be used (see 8.3).  
For an uncorrelated transmission (refer to Annex C subclause C.2.3.2 in [CEN/TR 17167:2018]  
the elapsed time between measurement and transmission shall be coded with the data point  
actuality duration(DP1!).  
15  
The nominal transmission interval used for synchronous transmission should be declared in  
installation datagrams (if available) with the data point “period of nominal data transmissions”  
(in seconds or minutes, DP3!).  
20  
Any due date value (identified with storage number 1 and no final DIFE according to Annex B,  
e.g. VM1!D) shall be accompanied by the respective due date (DT2!D). In this case the due  
date shall either be provided in the same message than the due date value or in the static  
frame.  
See also Annex G for rules of storage numbers in load profiles.  
25  
30  
35  
40  
8.4.5.2 Management Data  
Details about the error state indicated by status byte (see 7.2.3) shall either be coded with the  
data point “Error flags” (MM2!) or optionally with “Error flags (standard)” (MM3!).  
If a sequence number is needed (to prevent the detection of zero consumption refer to  
[EN 13757-7:2018], 7.5.5.2) it shall be coded as data point Unique message identification”  
(ID6!).  
For OMS end-device management the reception level of a received radio device can be  
transmitted with the data point “Reception or noise level” (refer to [EN 13757-3:2018], 6.4.4.1  
Table 12 Main VIFE code extension table, footnote d). This corresponds to M-Bus-Tag MM1!.  
If this data point is used together with the Function field 10b in DIF, it declares that the quality  
limit of the reception level was exceeded by the received radio device. Example: 21h FDh 71h  
9Ch marks a reception level > -100 dBm. This corresponds to M-Bus-Tag MM1!I.  
If this data point is used together with the Function field 11b, it declares the typical noise level  
detected by this radio device. Example: 31h FDh 71h 9Fh means a noise level of -97 dBm.  
This corresponds to M-Bus-Tag MM1!E.  
The applied DIN Address (see 3.2) of an OMS end-device can be provided in two data points.  
The original DIN Address supplied by the manufacturer is called “initial DIN Address” (ID7!).  
This address shall remain always unchanged and corresponds to the printed label. If an  
address element is subsequently changed by the operator, e.g. if a new device type is set, the  
new address can be given as “current DIN address” (ID8!).  
OMS GROUP  
76/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
8.4.5.3 Sensors  
Sensors according to this specification shall apply either a device type listed in Table 9 or the  
device type1Fh together with a concerning sub device type (ID11!) according to  
[prEN13757:2023], 6.5]. See also timing requirements in 4.3.2.3.  
5
8.4.6 OBIS Code  
The Object Identification System (OBIS) defines the identification codes for commonly used  
data items in metering equipment.  
These identification codes from DLMS-UA Blue Book are used for identification of:  
logical names of the instances of the interface classes, the objects  
data transmitted through communication lines  
data displayed on the metering equipment  
10  
15  
20  
OBIS-codes in addition are used for the market communication of different contract partners  
for the standardised exchange of metering values. M-Bus coded metering data needs a  
mapping to the relevant COSEM object instantiation with OBIS codes identifying the  
appropriate information. The Annex A defines a List of OBIS codes as subset of M-Bus-Tags  
from the OMS-DPL and the assigned OBIS codes. An OMS-Gateway that converts M-Bus  
data points to another Application Protocol shall add the respective OBIS code from the list.  
If an OMS end-device uses an M-Bus data point that is not listed in the OMS-DPL, but is  
required for billing purposes, the OBIS declaration should be transmitted by the OMS end-  
device itself. A radio device should transmit this OBIS declaration by a static message (see  
4.3.2.5). The OMS-Gateway then adds this OBIS declaration to the default OBIS conversion-  
table. The OBIS declaration via the M-Bus Application Protocol is described in  
[EN 13757-3:2018], Annex H.3.  
8.4.7 Descriptors  
25  
30  
35  
40  
M-Bus messages may contain several data points with the same VIB. They are separated  
using different Storage numbers, Tariff numbers, or Subunits (coded in the DIB). This allows  
the gateway to distinguish and group these data points e.g. using same Storage numbers.  
However, by default there is no information about the meaning of different storage, subunit or  
tariff numbers.  
Data points listed in the Annex A can be interpreted by the assignment to the given OBIS-  
Code (e.g. HC1!D and DT2!D, coded with Storage number 1, are defined as value at due date).  
Other data points (e.g. coded with Storage number 2) provide no information about the  
meaning and their interpretation may vary between manufactures.  
Descriptor data points (defined in Annex K) should be used to add a meaning to every data  
point group (e.g. all data points using Storage number 2 are used for monthly values). This  
enables the user to interpret the OMS end-device data points correctly. For some data points  
the usage of descriptors is mandatory (see Annex K).  
In case a descriptor is required, a unidirectional OMS end-device shall send it in each data  
message that contains a data point that needs the descriptor, or in each static message (see  
4.3.2.5). A bidirectional OMS end-device should send it in each data message that contains a  
data point that needs the descriptor, or in each static message. The gateway may also request  
descriptors from bidirectional OMS end-device using an Application select (see 8.10).  
8.4.8 Commands  
Further information on commands is given in Annex M.  
OMS GROUP  
77/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
8.5 DLMS Application Protocol  
The DLMS Application Protocol for CEN meters is described in [EN 13757-1:2014],  
[EN 62056-6-1:2013] and [DLMS UA].  
8.6 SML Application Protocol  
5
The SML Application Protocol is described in document [SML-spec].  
8.7 Clock Synchronisation Protocol  
If the gateway or the AMMHES provides the clock management service (according to Annex  
M, OMS-UC-04), the clock synchronisation protocol shall be applied. This protocol (time  
setting, time adjustment) is defined in the [prEN 13757-3:2023], Annex E.3. This annex defines  
criteria for periodical adjustments and adjustments on events. These criteria are not mandatory  
for OMS. Instead, the clock accuracy and the adjustment interval is in the responsibility of the  
gateway respectively AMMHES operator.  
10  
NOTE: The synchronisation of the OMS end-device clock may be in conflict with national laws.  
Check Annex E for details.  
15  
8.8 Application Error Protocol  
When an OMS end-device detects a failure in terms of authentication check, decryption,  
interpretation, or execution of a received command, it shall generate an application error. The  
presence of an application error should be announced in the Status field (see Table 17). Details  
of the application error may be requested by the gateway with a REQ-UD2. The application  
error shall remain until a respective state change event takes place (see Table 38).  
20  
The application error shall be transmitted with the generic Application Error Protocol as defined  
in [EN 13757-3:2018], clause 10 (see also Table 1 in 2.2).  
Table 40 lists application error codes that are harmonized by OMS. Other error codes of  
[EN 13757-3:2018], 10.3, Table 21 – “First error code byte for general application errorsare  
also allowed.  
25  
OMS GROUP  
78/143  
       
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Table 40 OMS Application error codes  
Error Designation  
code  
Description  
Application example  
01h CI-Field error  
Unimplemented CI-Field  
Too many records  
SITP not supported  
Too many M-Bus tags added  
(see Annex M, UC-14)  
Record  
03h  
overflow  
If a REQ-UD2 arrives before the  
application response has been  
generated  
Application  
busy  
Application too busy for handling readout  
request  
08h  
Second clock adjustment  
command while first one is still in  
process (see OMS-UC-04).  
If an unknown DIF/VIF-  
combination was received.  
If the access to the data source  
fails e.g. connection between  
adapter and OMS end-device  
broke.  
Command not  
10h  
The command is currently being  
processed and cannot be started again.  
yet finished  
Function not implemented (command  
unknown or not supported)  
11h No function  
12h Data error  
Data to be supplied are not available  
Clock adjustment command  
which exceed defined limit (see  
OMS-UC-04).  
Parameter  
error  
15h  
Parameter is missing or wrong  
Message  
17h  
Expected fields or communication layers Missing AFL or missing  
are not present or invalid in the message. AFL.MAC  
Message counter check, decryption or  
structure error  
20h Security error  
authentication fails or selected key is not Wrong AFL.MAC  
available  
Security  
21h mechanism not  
supported  
Security mode in the AFL/TPL in a SND- A SND-UD with security mode 8  
UD or SND-UD2 is not supported.  
was received.  
Inadequate  
22h security  
method  
A secured function like Clear  
status informationwas  
transmitted without SITP.  
Security method or key is not applicable  
for this function  
Application errors shall be transmitted unencrypted and not authenticated (see Table 42) as  
long as they are not wrapped in an application security protocol (see 9.4).  
NOTE 1: The Application Error Protocol can only be used for bidirectional communication.  
NOTE 2: An erroneous application select does not cause an application error (see 8.10).  
5
8.9 Security Management Protocol  
The Security Management Protocol provides services to establish and manage session based  
secured data transfer channels like TLS. It is initiated with specific CI-Fields (see Table 1).  
After a successful establishment the application data (e.g. M-Bus coded metering data initiated  
with CI = 72h) can be transferred within this secured channel.  
10  
15  
The structure of the security management data depends on the security mode defined in the  
TPL Configuration Field and other security mode specific fields in the Configuration Field/  
Configuration Field Extension. The first implementation of the Security Management Protocol  
is defined for the security mode 13 (see 9.3.8), which is needed for the OMS Security profile C  
using Transport Layer Security (TLS). Details are described in Annex F.  
8.10 Application Select Protocol  
The Application Select Protocol is used to request selected data from a bidirectional OMS end-  
device (according to [EN 13757-3:2018], clause 7). Table 41 shows the harmonized message  
applications and their relation to the fields content of message and content index. The  
application reset or select with CI-fields according to Table 1 acts as permanent application  
20  
OMS GROUP  
79/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
selection. If an application select is used without any parameter, then it acts as an application  
reset. An application reset forces the fall-back to the standard response (see [EN 13757-  
3:2018], clause 7).  
The application can also be selected with command setMM6!. Such a command applies a  
temporarily application select only (see Annex M, UC-14). The concerning command response  
is MM6!. Both the command and the response shall use a coding according to [EN 13757-  
3:2018], 7.2.  
5
The content of the static message (see 4.3.2.5) can also be reached with an application select  
to subcode 7 (see [EN 13757-3:2018], 7.2, Table 19 Coding of the message application). If  
the static message contains descriptors (see 8.4.7) they shall either be in block 0 or in block  
1.  
10  
If the OMS end-device does not support the selected application it shall apply an application  
reset according to [EN 13757-3:2018], 7.4.2.  
If the OMS end-device cannot provide the selected block number it shall select the first block  
of the selected application according to [EN 13757-3:2018], 7.5.  
15  
Table 41 List of message applications  
Message Related content Related content  
Description  
application of message CC  
(acc. to 7.2.4.7)  
index (acc. to  
07  
16  
17  
10b  
00b  
00b  
0000b  
0001b  
0010b  
Static content  
Data for mobile readout  
Data for fixed network readout  
Data for consumer information (acc.  
to Annex M, UC-07)  
18  
00b  
0011b  
26  
27  
28  
29  
46  
47  
48  
49  
54  
55  
56  
57  
00b  
00b  
00b  
00b  
01b  
01b  
01b  
01b  
01b  
01b  
01b  
01b  
0100b  
0101b  
0110b  
0111b  
0000b  
0001b  
0010b  
0011b  
1000b  
1001b  
1010b  
1011b  
Manufacturer specific usage  
Manufacturer specific usage  
Manufacturer specific usage  
Manufacturer specific usage  
Add. data for fixed network readout  
Add. data for fixed network readout  
Add. data for fixed network readout  
Add. data for fixed network readout  
Add. data for fixed network readout  
Add. data for fixed network readout  
Add. data for fixed network readout  
Add. data for fixed network readout  
OMS GROUP  
80/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
9 Security  
9.1 General  
The Open Metering System provide security mechanism for the  
Communication security (see 9.3) to protect the link between the OMS end-device and  
the communication partner and  
Application security (see 9.4) to protect and authorise application services  
5
10  
15  
Sub-clause 9.2 defines the rules for the applicable keys.  
To protect the privacy of the consumer, all wireless communication containing consumption  
data shall be encrypted (according to 9.3). For wired communication, the  
encryption/authentication is optional (according to 9.3).  
However, if encryption for the communication channel is enabled not all messages need to be  
encrypted. Table 42 lists for each protocol / layer whether or not the encryption/authentication  
is required, possible, or not allowed, in case of enabled security profile. Messages without a  
transport layer are generally not encrypted.  
Even if encryption for an application protocol is required, some data points like Identification or  
Fabrication number need to be transmitted unencrypted. Annex B.2 lists for each M-Bus data  
point whether or not the encryption (according to 9.3) is required, possible, or not allowed.  
Annex F lists requirements for encryption/authentication of TLS-handshake messages.  
Annex E lists additional national requirements.  
20  
Table 42 Encryption and authentication of application protocols  
CI-Field  
50h a  
Protocol / Layer  
Encryption  
Authentication  
Application Reset or Select  
Command (M-Bus)  
N/A  
Off  
51h a  
N/A  
Off  
52h  
Selection of Device  
N/A  
Off  
53h, 57h e  
54h a  
Application Reset or Select  
Request of selected application  
Request of selected application  
Command (M-Bus)  
On  
N/A  
N/A  
Off  
55h, 56h e  
5Ah, 5Bh g  
5Fh f  
On  
On  
Command (TLS-HS)  
60h, 61h b, f  
64h, 65h b, f  
66h a  
Command (DLMS)  
On  
On  
Off  
On  
On  
Off  
Command (SML)  
Response of selected application  
Response of selected application  
Time Sync  
67h, 68h e  
6Ch, 6Dh, 62h  
6Eh, 6Fh c, h  
Application Error  
OMS GROUP  
81/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Table 42 (continued)  
CI-Field  
70h  
Protocol / Layer  
Application Error  
Alarm  
Encryption  
Authentication  
N/A  
Off  
71h  
N/A  
Off  
e
74h, 75h  
Alarm  
On  
Off  
72h, 7Ah g  
7Ch, 7Dh b, f  
7Eh, 7Fh b, f  
Response (M-Bus)  
Response (DLMS)  
Response (SML)  
On  
see Annex B.2 d  
On  
On  
80h, 8Ah, 8Bh, 93h Pure Transport Layer  
Off  
9Eh, 9Fh f  
B8h  
Response (TLS-HS)  
N/A  
Set baud rate to 300 baud  
Set baud rate to 2400 baud  
Set baud rate to 9600 baud  
Set baud rate to 19200 baud  
Set baud rate to 38400 baud  
Off  
Off  
Off  
Off  
Off  
BBh  
N/A  
BDh  
N/A  
BEh  
N/A  
BFh  
N/A  
C0h, C1h, C2h,  
C7h e  
Image transfer  
On  
On  
C3h, C4h, C5h,  
C6h e, h  
Security Information Transfer  
Encryption is mandatory. A Security mode > 0 shall be applied.  
Encryption is not allowed. Security mode 0 shall be applied.  
Not applicable  
N/A  
a
These CI-Fields are not applicable, if the communication requires a Security profile (see Table 44).  
These commands/responses encrypt and authenticate data using either the security services of  
AFL/TPL (according to this specification) or APL specific security methods.  
For Security profile C the encrypted transmission of application errors is allowed. For details see  
Not all data points need to be encrypted. The size of encrypted data may vary from zero to full data  
length.  
In case data need to be padded before encryption, TPL-padding acc. to [EN 13757-7:2018], 9.4.5.4  
shall be used.  
TPL-padding acc. to [EN 13757-7:2018], 9.4.5.4 is optional.  
In case data need to be padded before encryption, padding value 2Fh in the application protocol  
shall be used.  
Application protocol wrapped in SITP will use TPL encryption and authentication according to  
b
c
d
e
f
g
h
NOTE 1: Column “authentication” shall be ignored if a security profile is applied, that does not support  
authentication, e.g. Security Profile A.  
NOTE 2: If no encryption and no authentication is required, Security mode 0 (see 9.3.4) can be  
used.  
The usage of a MAC (see 9.3.3) ensures the integrity and the authenticity of the transferred  
data.  
A persistent key is usually configured to an OED by an operator action and has a long validity  
time. It can be used for encryption, authentication, or key derivation. For some cipher methods  
a key is derived from the persistent key. Such a key is called ephemeral key and is used for  
encryption or authentication. It has a short validity time or is used only once.  
5
OMS GROUP  
82/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Table 43 provides an overview of the supported security profiles. Each profile presents a valid  
combination of the encryption method, message authentication, and the length and type of  
used key.  
Table 43 OMS Security profiles  
Profile  
Encryption  
Authentication  
Key  
No Security No encryption  
profile  
No MAC (MAC-Mode  
AT = 0) b  
No key  
(Security Mode 0) a  
Security  
AES128-CBC  
No MAC (MAC-Mode  
AT = 0) b, d  
128 bit persistent symmetric  
key (with KeyID acc. to  
profile A g  
(Security Mode 5) a, d,  
Security  
profile B  
AES128-CBC  
CMAC (8 Byte trunc.)  
(MAC-Mode AT = 5) d, e  
128 bit ephemeral  
(Security Mode 7) a, d  
symmetric key (derived by  
KDF from persistent key  
with KeyID acc. to 9.2.2)  
Security  
profile C  
TLS 1.2  
HMAC (TLS1.2) and  
additional CMAC (8 Byte  
trunc.)  
256 bit elliptic curve key  
(384 bit optional) for TLS  
and  
(Security Mode 13) a, d  
(MAC-Mode AT = 5) d, e for 128 bit ephemeral  
communication  
establishment  
symmetric key (derived by  
KDF from persistent key  
with KeyID acc. to 9.2.2) for  
CMAC c  
Security  
profile D  
AES128-CCM  
CCM (8 Byte)  
(OO=01b) d, f  
128 bit ephemeral  
(Security Mode 10) a, d  
symmetric key (derived by  
KDF from persistent key  
with KeyID acc. to 9.2.2)  
a
Declared in Configuration Field CF (see 7.2.4)  
If AFL is not present the default interpretation is AT = 0.  
During the TLS-handshake the usage of the CMAC is also required. However, the normal data  
exchange of Mode 13 applies the HMAC of the TLS protocol for message authentication.  
The following message types shall apply Security mode 0 and no AFL: REQ-UD1, REQ_UD2,  
SND-NKE, ACC-NR, ACC-DMD, ACK, NACK, CNF-IR  
Declared in AFL.MCL (see [EN 13757-7:2018]).  
Declared in CFE of security mode 10 (see 7.2.4.5)  
The security profile A will be deprecated and is not recommended by OMS for future development.  
b
c
d
e
f
g
5
OMS GROUP  
83/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Table 44 defines which Security profiles shall be supported by the OMS end-device and the  
Table 44 Required Security profiles  
Communication  
OMS end-device  
OMS-Gateway  
Wireless, unidirectional  
communication  
Security profile A  
Security profile A  
and  
or  
(according to 4.3)  
Security profile B  
or  
Security profile B  
and  
Security profile D  
Security profile D  
Wireless, bidirectional  
communication  
Security profile A  
Security profile A  
and  
Security profile B  
and  
or  
(according to 4.3) a  
Security profile B  
or  
Security profile C  
or  
Security profile D  
Security profile D  
and optionally  
Security profile C  
Wired communication  
(according to 4.2)  
No security profile  
No security profile  
and  
or  
Security profile A  
Security profile A  
and  
or  
Security profile B  
or  
Security profile B  
and  
Security profile D  
or  
Security profile C  
Security profile D  
and optionally  
Security profile C  
a
In addition to the security profiles listed here, "no security profile" may be used by LPWAN  
communications, as far as the LPWAN communication provides similar security services as shown  
The manufacturer shall declare all supported security profiles in the data sheet of an OMS end-  
device or gateway. During operation the OMS end-device is not allowed to change the  
configured security profile by itself. The security profile can only be changed with an OMS end-  
device configuration procedure initiated e.g. by the MSO.  
5
NOTE: The asymmetric encryption (e.g. Security profile C) of bidirectional communication is  
necessary for certain countries due to national laws. It can provide a higher security level for  
transmissions where AES-based encryption with shared keys is not sufficient. Annex E  
provides a guideline to solutions which meet the known national requirements.  
10  
9.2 Key Management  
9.2.1 General  
An OMS end-device has one or several keys. If an OMS end-device provides access for  
different users or if it has different communication end points (like gateway or AMMHES) then  
different keys have to be used. Keys with different purpose can be identified by the KeyID (see  
9.2.2). A key used for replacement of an existing key, applies the same KeyID but a different  
KeyVersion (see [EN 13757-7:2018]). An OMS end-device has at least the master key MK.  
15  
9.2.2 KeyID  
20  
Each key is defined for one specific purpose. The KeyID is used to identify the key and its  
usage. Table 45 lists available KeyID. Changing one key shall not have any effect on keys  
with other KeyID.  
Table 45 Predefined OMS-KeyIDs  
OMS GROUP  
84/143  
         
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Techno- Key-ID (Hex) Usage  
logy  
Responsible  
00h  
Master key (MK), default communication security key  
OMS-Group  
Manufacturer  
OMS-Group  
01h to 07h  
08h  
Manufacturer specific communication security key  
Harmonised communication security key (see Annex M,  
OMS-UC-07b)  
09h to 0Eh  
0Fh  
Reserved for harmonised communication security keys  
OMS-Group  
OMS-Group  
MAC key, persistent key for OMS LPWAN MAC security  
10h  
Root wrapper key applicable to wrapper keys with a  
KeyID 10h to 16h;  
OMS-Group  
(see Figure 25 and Annex M; OMS-UC-08)  
11h  
12h  
Reserved for wrapper keys  
OMS-Group  
OMS-Group  
Communication security wrapper key; applicable to  
communication security keys with KeyID 00h and 08h  
to 0Fh; optional applicable to KeyID 01h to 07h  
(see Figure 25 and Annex M, OMS-UC-08)  
13h  
14h  
Reserved for wrapper keys  
OMS-Group  
OMS-Group  
Application security wrapper key;  
applicable to APL keys with a  
KeyID 18h to 2Fh  
(see Figure 25 and Annex M, OMS-UC-08)  
15h  
16h  
17h  
18h  
Reserved for wrapper keys  
Reserved  
OMS-Group  
OMS-Group  
Manufacturer  
OMS-Group  
Manufacturer specific wrapper key  
Authentication key for firmware image protection (See  
Annex M, OMS-UC-05)  
19h to 1Eh  
1Fh  
Reserved  
OMS-Group  
OMS-Group  
Application security key for OMS compliance test (See  
Annex M, OMS-UC-00)  
20h  
21h  
22h  
23h  
24h  
25h  
26h  
27h  
Application security key for disconnection & reconnection OMS-Group  
(See Annex M, OMS-UC-03)  
Application security key for clock adjustment (See Annex OMS-Group  
M, OMS-UC-04b/-04c)  
Application security key for clock setting (See Annex M,  
OMS-UC-04b/-04c)  
OMS-Group  
OMS-Group  
OMS-Group  
Application security key for update of firmware image  
(See Annex M, OMS-UC-05)  
Application security key for OMS end-device supervision  
(See Annex M, OMS-UC-06)  
Application security key for data selection (See Annex M, OMS-Group  
OMS-UC-14)  
Application security key for application management (See OMS-Group  
Annex M, OMS-UC-12)  
Application security key for settings of an adapter (See  
Annex M, OMS-UC-20)  
OMS-Group  
28h to 2Fh  
30h to 4Fh  
50h to 5Fh  
60h to 7Fh  
Reserved for harmonised APL-Keys  
Manufacturer specific APL-Keys  
Reserved for harmonised APL-Keys  
Reserved  
OMS-Group  
Manufacturer  
OMS-Group  
-
OMS GROUP  
85/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Table 45 Predefined OMS-KeyID (cont.)  
Techno- Key-ID (Hex) Usage  
logy  
Responsible  
80h to AFh  
B0h to BFh  
C0h to EFh  
F0h to FFh  
Defined in Annex F  
OMS-Group  
OMS-Group  
Manufacturer  
-
Reserved for harmonized Keys  
Manufacturer specific Keys  
Reserved  
NOTE: Communication security keys used for security services in TPL and AFL can apply only  
KeyID-numbers from 00h to 0Fh.  
9.2.3 Key Generation  
5
The master key (KeyID = 0) shall be generated by a cryptographic random generator.  
The master key shall be generated for each device individually.  
The communication security key with KeyID = 8 shall apply to the same rules as the master  
key.  
NOTE: Possible references for random generators are [BSI_TR-02102-1] or [NIST_800-133].  
10  
9.2.4 Key Exchange  
The OMS end-device may have several keys. Each key is used for a special purpose and can  
be identified by the KeyID (see 9.2.2). The key exchange uses the Security information protocol  
according to [EN 13757-7:2018], Annex A. Details for the exchange of symmetric keys are  
defined in Annex M, OMS-UC-08.  
15  
20  
Symmetric and asymmetric keys used for Security profile C require a specific key exchange  
procedure as defined in Annex F.  
The key exchange requires so called wrapper keys, which are used to wrap the new key in a  
secured container before the key is transferred to the OMS end-device. There is a wrapper  
key for the communication security keys used in the AFL/TPL and another wrapper key for the  
application security keys used in the APL. The wrapper keys themselves can be exchanged  
only by the root wrapper key. The root wrapper key itself is also exchangeable by the root  
wrapper key. The root wrapper key shall not be used to exchange other keys than wrapper  
keys. Following figure illustrates the key hierarchy.  
OMS GROUP  
86/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Figure 25 Keys used for the key exchange of symmetrical keys.  
The root wrapper key is the security basis for all other keys. The owner of this key has the  
possibility to change all other keys. Therefore, it shall never be forwarded to other parties. The  
owners of other keys (wrapper keys, communication security keys) can recognize an  
(unwanted) interference by the root wrapper key with help of the key version of the respective  
key (increased key version number in that case).  
5
9.2.5 Key Derivation Function  
9.2.5.1 General  
If an ephemeral key is required then the key shall be generated using the key derivation  
function defined below. This ephemeral key shall be used for one message only. The key  
derivation function shall apply the CMAC function according to [RFC4493]. There are five input  
values to the KDF specified in 9.2.5.2 to 9.2.5.6.  
10  
9.2.5.2 Communication Security Key (CSK)  
Before each transmission up to two ephemeral keys, Kenc (for encryption) and Kmac (for  
authentication), are derived from the individual communication security key CSK. There are  
two sets of key pairs (one set for the OMS end-device Kenc/Kmac and one set for the gateway  
Lenc/Lmac).  
15  
If nothing else is defined the master key (MK) shall be used as communication security key  
(CSK).  
20  
25  
The initial master key MK0 (provided by the manufacturer) has the KeyID = 0 and the  
KeyVersion = 0. If the OMS end-device provides Security Profile C according to Annex E.1 this  
initial master key MK0 shall be stored permanently and shall not be removed or replaced when  
the operator provides a new master key. A new master key will get the same KeyID but a  
different KeyVersion. The initial master key MK0 is linked to a dedicated initial message counter  
CM0 (see 9.3.2.3).  
OMS GROUP  
87/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
9.2.5.3 Derivation Constant (DC)  
The constant is used to derive different keys for both Encryption and Authentication as well as  
for the two directions - from and to the OMS end-device.  
Table 46 Constant (DC) for the key derivation  
DC  
Used for  
00h Encryption from the OMS end-device  
(Kenc)  
01h MAC from the OMS end-device (Kmac)  
10h Encryption from the gateway (Lenc)  
11h MAC from the gateway (Lmac)  
5
10  
15  
9.2.5.4 Message counter  
The KDF applies the message counter to generate a unique ephemeral key for each new  
message. The message counter shall be according to 9.3.2.  
9.2.5.5 Device ID  
The device ID used in the key derivation function corresponds to the Identification Number of  
the OMS end-device address.  
The location of this address in uplink and downlink messages is defined in 3.1.  
9.2.5.6 Padding  
To avoid the generation of the K2 (refer to [RFC4493]) in the KDF, the remaining bytes of the  
16 byte block are filled with a padding sequence. For the generation of Kmac, Lmac and Kenc,  
Lenc the padding is fixed and consists of seven octets each containing the value of 07h  
according to the rule that the input to the MAC shall be padded with (16-l mod 16) bytes with  
value (16-l mod 16), where l equals the byte length of the input.  
9.2.5.7 Key calculation  
The calculation of encryption and authentication key:  
20 K = CMAC( CSK , DC || C || ID || 07h || 07h || 07h || 07h || 07h ||  
07h || 07h )  
Where  
CSK is individual communication security key (according to 9.2.5.2)  
DC  
C
is Derivation constant (according to 9.2.5.3)  
is message counter CM, C’M, C’’M, CGW or C’GW (according to 9.2.5.4)  
is Device ID (according to 9.2.5.5)  
25  
ID  
Multi byte fields C and ID are arranged in the same order as in the transmitted frame.  
The derived key K can be Kenc, Kmac, Lenc, Lmac depending on selected Derivation constant  
30  
Figure 26 in 9.3.2.2 and Figure 27 in 9.3.2.4 provides a detailed sequence diagram for  
transmitting and receiving messages using a derived key.  
OMS GROUP  
88/143  
           
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
9.3 Communication security  
9.3.1 General  
Communication security protects the communication between the OMS end-device and the  
communication partner like the gateway. It covers protection of privacy and integrity. It also  
prevents a zero-consumption detection. The encryption applies only to the application protocol  
and the decryption verification and TPL-padding (if present).  
5
In case of several communication partners, the OMS end-device has to maintain an individual  
message counter for each applied communication security key.  
The security mode in use is indicated in the Configuration Field (see 7.2.4).  
10  
9.3.2 Message counter  
9.3.2.1 Overview  
Ephemeral keys are generated by inclusion of a strictly monotonously increasing (non-secret)  
counter in the KDF. This counter is transmitted either in the AFL.MCR field for security profile  
B and C (see [EN 13757-7:2018], 6.3.5) or in the TPL for security profile D (see  
[EN 13757-7:2018], 7.7.8). The message counter maintained and transmitted by the OMS end-  
device is named CM, the message counter maintained and transmitted by the communication  
15  
partner (typically the gateway) is named CGW  
.
A copy of this message counter stored by the receiver of the message is marked as C’  
respectively C’’.  
20  
25  
The following set of counters is needed for data exchange:  
CM  
CGW  
counter used by the OMS end-device as message counter;  
counter used by the communication partner as message counter;  
C’GW unverified copy of CGW used by the OMS end-device;  
C’M  
C’’M  
unverified copy of CM used by the communication partner;  
verified copy of CM used by the communication partner;  
The OMS end-device counter CM is the leading counter in the system.  
NOTE: The message counter is required for Security profile B, C and D (see 9.1)!  
An example for the handling of the message counter is provided in Annex J.  
9.3.2.2 Message counter handling in an OMS end-device  
30  
CM is used for the derivation of keys applicable to messages transmitted from the OMS end-  
device to the communication partner.  
The initial value of CM is 0. The OMS end-device shall increment CM by 1 prior to generating  
an authenticated and encrypted message.  
CM shall be updated, if an authenticated and valid message counter CGW from a communication  
partner was received as shown in Figure 26.  
35  
When the counter CM reaches the maximum value FFFFFFFFh it shall not wrap around with  
the next increment. In this case the OMS end-device should stop any transmission.  
In case the individual master key (KeyID K = 0) of the OMS end-device is changed, the counter  
CM shall be reset to the initial value.  
40  
Figure 26 shows the handling of the message counter in an OMS end-device for both  
transmitting and receiving a message.  
OMS GROUP  
89/143  
       
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Figure 26 Handing of the message counter in the OMS end-device  
OMS GROUP  
90/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
9.3.2.3 Initial Message Counter CM0  
If an OMS end-device provides Security Profile C according to Annex F, it has to maintain an  
additional message counter called initial message counter CM0. This specific message counter  
is only linked to the initial master key MK0 (see 9.2.5.2). The initial value of CM0 is 0. It shall  
only be increased, if the initial master key MK0 is active. A reset of the initial message counter  
is never possible. The last value of the initial message counter must always be stored (and  
proceeded) for a later communication with the initial master key in case of a “Reset of MK0”.  
5
The message counter CM shall not be influenced by the initial message counter CM0. If a new  
master key is used, the message counter CM will be reset. The initial message counter CM0 is  
not harmed by this process.  
10  
9.3.2.4 Message Counter Handling in a Communication Partner  
CGW is used for the derivation of keys applicable to messages transmitted from the  
communication partner to the OMS end-device.  
NOTE: The communication partner supports an independent message counter CGW for each  
15  
connected OMS end-device.  
The initial value of CGW for each OMS end-device is 0.  
CGW shall be updated, if an authenticated message counter CM from OMS end-device was  
received as shown in Figure 27.  
The communication partner shall increment CGW prior to generating an authenticated and  
encrypted message. The increment shall not exceed the value of 100.  
20  
When the counter CGW reaches the maximum value FFFFFFFFh it shall not wrap around with  
next increment. In this case the communication partner should stop any transmission to this  
OMS end-device.  
When the communication partner receives a message counter CM ≥FFFF0000h it should set  
the OMS end-device in error condition to trigger a service action (e.g. master key exchange)  
before the message counter of the OMS end-device reaches the maximum value.  
25  
Figure 27 shows the handling of the message counter in a communication partner for both  
transmitting and receiving a message.  
OMS GROUP  
91/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Figure 27 Handing of the message counter in the communication partner  
NOTE: Because of the short time window for replying to a wireless M-Bus datagram, a  
communication partner may calculate the encryption key and authentication key in advance,  
based on the assumption of a message counter value (CM’’).  
OMS GROUP  
92/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
9.3.3 MAC-Generation  
9.3.3.1 CMAC (AES 128 8 Byte Truncated)  
The authentication of the message is supported by the AFL (option AT = 5 see  
[EN 13757-7:2018]) using the MAC. This MAC shall be calculated as specified in AES128 for  
Crypto-Message-Authentication (CMAC-AES128) according to [RFC4493]. The MAC shall be  
calculated as follows:  
5
MAC = CMAC (Kmac/Lmac, AFL.MCL || AFL.MCR[7..0] || AFL.MCR[15..8] ||  
AFL.MCR[23..16] || AFL.MCR[31..24] || { AFL.ML[7..0] ||  
AFL.ML[15..8] || } NextCI || ... || Last Byte of message)  
10 AFL.MAC = trunc(MAC)  
The presence of the AFL.ML field depends on the selection bits in the AFL.MCL field.  
The MAC shall be calculated after the encryption. The MAC of a received message shall be  
verified before decryption.  
An example is given in Annex N.  
15  
For a transmission from communication partner to OMS end-device the key Lmac is used. For  
a transmission from OMS end-device to communication partner the key Kmac is used (see key  
calculation in subclause 9.2.5.7).  
The resulting 16 byte of this CMAC-function shall be truncated to 8 bytes as defined in  
[RFC4493]. Thus, the first 8 bytes beginning with the MSB shall be taken in the field AFL.MAC.  
20  
In deviation to the usual transmission order for octet strings on the M-Bus, the MSB of the MAC  
shall be transmitted as first byte, the LSB as last.  
9.3.3.2 HMAC (TLS1.2)  
The TLS1.2 requires a HMAC for the authentication of the payload. TLS message  
authentication is part of the TLS protocol. See Annex F for details.  
25  
9.3.4 No Encryption with Security Mode 0  
If security mode 0 is selected, then all following data are transmitted plain.  
9.3.5 Symmetric Encryption with Security Mode 5  
Symmetric encryption is performed with security mode 5. It uses AES-CBC with a persistent  
key of 128 bits and a specific dynamic initialisation vector based on the Access Number of the  
Transport Layer. The initialisation vector requires the usage of the Access Number. Be aware  
that the initialisation vector shall always apply the Access Number from the Transport Layer  
whether or not the Extended Link Layer exists. The security mode is defined in [EN 13757-  
7:2018], 9.4.4.  
30  
35  
The data to be encrypted shall be padded to a multiple of 16 bytes before encryption. The  
padding method depends on the selected application protocol (refer to Table 42).  
Annex N shows examples with both unencrypted and encrypted data.  
9.3.6 Symmetric Encryption with Security Mode 7  
Symmetric encryption is performed with security mode 7. It uses AES-CBC with an ephemeral  
key of 128 bits and a static initialisation vector IV = 0 (16 Bytes of 00h). The security mode is  
defined in [EN 13757-7:2018], 9.4.5.  
40  
OMS GROUP  
93/143  
         
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
The ephemeral key shall be generated with a key derivation function (KDF), which is described  
in subclause 9.2.5.  
For ensuring the integrity and authenticity, the CMAC as described in subclause 9.3.3.1 shall  
be used.  
5
Applying the security mode 7 always requires the usage of the AFL (see clause 6), since the  
message counter C (see 9.2.5.4) is needed for the KDF and transmitted in the AFL.  
The data to be encrypted shall be padded to a multiple of 16 bytes before encryption. The  
padding method depends on the selected application protocol (refer to Table 42).  
Annex N shows examples with both unencrypted and encrypted data.  
10  
15  
20  
9.3.7 Symmetric Authenticated-Encryption with Security Mode 10  
Symmetric authenticated-encryption is performed with security mode 10. It uses AES-CCM  
with an ephemeral key of 128 bits. The security mode is defined in [EN 13757-7:2018], 9.4.8.  
The ephemeral key shall be generated with a key derivation function (KDF), which is described  
in subclause 9.2.5. Applying the security mode 10 does not require the usage of the AFL, since  
the message counter MC (see 9.2.5.4) needed for the KDF is transmitted in the TPL of security  
mode 10 and since the authentication is provided with an authentication tag in the TPL of  
security mode 10.  
The CCM of security mode 10 ensures integrity and authenticity by including an 8 byte  
authentication tag. The authentication tag is further providing decryption verification.  
The data to be encrypted does not need to be padded before encryption.  
Refer to Annex D for further information on the TPL-structure of security mode 10.  
9.3.8 Asymmetric Encryption with Security Mode 13  
Security Mode 13 describes an asymmetric encryption method based on Transport Layer  
Security (TLS). Security mode 13 is defined in Annex F.  
25  
NOTE: It should be noted that the TLS (Transport Layer Security) according to Security  
profile C is independent from the KDF and CMAC. Nevertheless, the CMAC is required for the  
TLS-handshake procedure to protect it against DoS attacks6.  
9.4 Application security  
9.4.1 General  
30  
35  
The communication security (according to 9.3) is used to protect the link between the  
communication partner and the OMS end-device. Critical functions may be separately  
protected, to avoid unintended or unauthorised actions by users with access to the metering  
system. The application security provides the service of an additional security level in the  
application layer.  
The application security is not an alternative to the communication security but has to be  
applied additionally for critical functions. Following figure illustrates the different access rights  
of User1 and User2 provided by the application security.  
6
A denial-of-service (DoS) attack is an attempt to make a service unavailable to its intended users.  
OMS GROUP  
94/143  
         
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
User 1  
OMS end-device  
Gateway  
AMM Head-End System  
App.  
 Read  
M-Bus  
Commu-  
nication  
M-Bus  
Commu-  
nication  
WAN  
Commu-  
nication  
WAN  
User-  
Commu-  
Interface  
nication  
KUSER2  
App.  
User 2  
 Write  
KUSER2  
Communication  
security with  
the Master Key  
Transport security  
(like TLS) in the WAN  
Secured  
Intranet  
End to end application  
security with user keys  
Figure 28 Application security versus Communication security  
To protect critical services of an OMS end-device against unauthorised usage, the critical  
application command or response are encapsulated in a specific secured protocol. This  
protocol is called Security Information Transfer Protocol (SITP). The SITP is defined in  
[prEN 13757-7:2023], Annex A.  
5
The usage of the SITP is required  
To support selected use cases (described in Annex M) and  
To allow key exchange in Security profile C.  
10  
NOTE: Typically, the commands to be secured by application security are enciphered in the  
AMM Head-End System, whereas the communication or transport security is applied in the  
communication partner. For this reason, it is essential that the application security applies  
different keying material than the communication security.  
OMS GROUP  
95/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
9.4.2 Application security profile  
9.4.2.1 Overview  
Table 47 describes the Application security profiles that may be supported by an OMS end-  
device. The mandatory or optional use of Application security profiles are defined in Annex M.  
5
Table 47 OMS Application security profiles  
Profile  
No  
Application  
Cipher method  
According to:  
Key Exchange (symmetrical  
keys only)  
Key wrap based on  
AES128  
[prEN 13757-7:2023],  
Annex A, A.8  
ASP01  
ASP02  
ASP03  
Exchange of security  
information for Security  
profile C  
Key wrap based on  
AES128 + ASN.1 DER appendix F.A  
Authentication of a firmware  
image  
CMAC (16 Byte) based [prEN 13757-3:2023], Annex I,  
on AES128  
I.2.4.6 (MAC Algorithm ID 04h)  
ASP04 to Reserved  
ASP09  
End to end authenticated  
application data  
CMAC (8 Byte) based  
on AES128  
[prEN 13757-7:2023],  
Annex A, A.9.4  
(DSI 32h)  
ASP10  
ASP11 to Reserved  
ASP19  
End to end secured application AES-CCM (8 Byte)  
ASP20 a data  
based on AES128  
[prEN 13757-7:2023],  
Annex A, A.9.7  
(DSI 36h)  
a
This ASP is intended for use cases that need additional confidentiality.  
Each Application security profile shall be used together with a special KeyID. The applicable  
KeyID’s are described in 9.2.2.  
All keys applied for application security are 128 bit persistent symmetric keys.  
9.4.2.2 ASP01 - Key Exchange  
10  
This Application security profile is used together with use case “Key management” (see Annex  
M, OMS-UC-08). It allows a secured exchange of symmetrical keys (see 9.2.4) in the OMS  
end-device.  
9.4.2.3 ASP02 - Exchange of Security Information for Security Profile C  
The SITP is also used for the exchange of security information of Security profile C. Because  
this Security profile applies an asymmetrical crypto mechanism the SITP-protocol has been  
extended. The Annex F defines the extension of SITP.  
15  
9.4.2.4 ASP03 Authentication of a Firmware Image  
This Application security profile is only used together with the use case “Firmware update” (see  
Annex M, OMS-UC-05). It provides an Authentication of the transferred firmware image.  
20  
9.4.2.5 ASP10 - End to End Authenticated Application Data  
This profile allows transferring application data in an authenticated SITP container. The OMS  
end-device shall only accept messages, if the verification of the authentication has been  
passed.  
The transported application protocol is identified by the Protocol Identifier field (PID). The  
Annex M lists the applicable PIDs for each use case.  
25  
OMS GROUP  
96/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
9.4.2.6 ASP20 - End to End Secured Application Data  
This profile allows transferring application data in a secured (confidential and authenticated)  
SITP container. The OMS end-device shall only accept messages, if the verification of the  
security has been passed.  
5
The transported application protocol is identified by the Protocol Identifier field (PID). The PID  
is same link in 9.4.2.5.  
OMS GROUP  
97/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex  
Annex A (Normative): List of OBIS Codes for OMS end-  
devices  
The list of OBIS codes provides a translation between an M-Bus-Tag and a relevant COSEM  
object instantiation with OBIS code identifying the appropriate information. This list is  
applicable when the M-Bus-data points are converted to another protocol.  
5
This annex may be subject to a more frequent update than this main document. Therefore, the  
annex is not included. The current version (Release F or later) can be downloaded from the  
OMS website (www.oms-group.org).  
OMS GROUP  
98/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex B (Normative): OMS-Data Point List  
This annex provides a list of all M-Bus-Tags supported by the OMS.  
This annex may be subject to a more frequent update than this main document. Therefore, the  
annex is not included. The current version (release G or later) can be downloaded from the  
OMS website (www.oms-group.org).  
5
OMS GROUP  
99/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex C (Empty)  
This annex is intentionally left blank.  
NOTE: This annex has been used until OMS-S2, v 4.5.1. With the revision of sensors in [prEN  
13757-3:2023] and [prEN 13757-7:2023] all necessary definitions for sensors are inside this  
document.  
5
OMS GROUP  
100/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex D (Informative):  
The Structure of the Transport and Application Layer  
The TPL/APL (starting from the TPL-CI-Field) uses one of the following frame structures.  
NOTE: These structures show only fields used by OMS. According to [EN 13757-7:2018] more  
5
fields may occur before and after the application data.  
D.1 No TPL-header  
The No TPL-header may be used on wired M-Bus. The application protocol starts immediately  
after the CI-Field.  
10  
TPL/APL without TPL-header  
No message identification by Access Number, Status or encryption possible.  
Applied from master with CI = 50h; 51h; 52h; 54h  
Applied from slave with CI = 66h; 70h; 71h  
CI  
Data  
15  
TPL without TPL-header  
No message identification by Access Number, Status or encryption possible.  
Applied from master with CI = B8h … BFh  
CI  
D.2 Short TPL-header  
The Short TPL-header can be applied if the OMS end-device application address is identical  
with the link address of the wireless M-Bus OMS end-device. On wired M-Bus, the Short TPL-  
header is applicable in downlink only.  
20  
TPL/APL with Short TPL-header  
Applied from master with CI = 56h, 57h, 5Ah; 61h; 62h, 65h, 92h, C6h, C7h  
Applied from slave with CI = 67h; 6Eh; 74h; 7Ah; 7Dh; 7Fh; 88h, 9Eh, C1h, C4h  
25  
CF/  
CFE  
CI  
ACC  
STS  
(KV)  
(MC)  
(DV)  
Data  
(AT)  
NOTE: The fields in brackets exists only in case of special security modes (see D.4).  
TPL with Short TPL-header  
Applied from master with 93h  
Applied from slave with CI = 8Ah  
30  
CF/  
CFE  
CI  
ACC  
STS  
OMS GROUP  
101/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
D.3 Long TPL-header  
If the OMS end-device application address differs from the link address of the wireless M-Bus  
OMS end-device or if a wired M-Bus OMS end-device is used, then the Long TPL-header with  
support of mandatory Secondary Address shall be applied.  
5
TPL/APL with Long TPL-header  
Applied from master with CI = 53h, 55h, 5Bh; 5Fh; 60h; 64h; 6Ch, 6Dh, C0h, C3h  
Applied from slave with CI = 68h; 6Fh; 72h; 75h; 7Ch; 7Eh; 9Fh, C2h, C5h  
Ident.  
No  
Dev.  
Type.  
CF/  
CFE  
CI  
Manuf.  
Ver.  
ACC  
STS  
(KV)  
(MC)  
(DV)  
Data  
(AT)  
NOTE: The fields in brackets exists only in case of special security modes (see D.4).  
10  
TPL with Long TPL-header  
Applied from master with 80h  
Applied from slave with 8Bh  
Ident.  
No  
Dev.  
Type  
CF/  
CFE  
CI  
Manuf.  
Ver.  
ACC  
STS  
D.4 Legend  
15  
CI  
Control Information Field  
Ident. no  
Manuf.  
Ver.  
Identification Number (part of OMS end-device application address)  
Manufacturer ID (part of OMS end-device application address)  
Version (part of OMS end-device application address)  
Dev. Type  
ACC  
Device Type (part of OMS end-device application address)  
20  
25  
30  
Access Number (from master initiated session uses Gateway Access  
Number; from slave initiated session uses Meter Access Number)  
STS  
Status (from master to slave) used for gateway status (RSSI);  
(from slave to master) used for OMS end-device status  
CF/ CFE  
(KV)  
Configuration Field / Configuration Field Extension  
KeyVersion (only present in security mode 10 and only if enabled in the  
CF/CFE)  
(MC)  
(DV)  
Message counter (only present in security mode 10)  
Decryption Verification a two-byte sequence 2Fh 2Fh (only present in  
security mode 5 and 7)  
(AT)  
Data  
Authentication Tag located in the TPL-Trailer (only present in security  
mode 10).  
Application data; coding depends on used Application or Service  
Protocol  
OMS GROUP  
102/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex E (Normative):  
Communication profiles for compliance with national  
regulations  
A national law may require additional demands on the security of OMS end-device  
communication. This annex lists the applicable communication profiles in order to comply with  
the national regulation.  
5
Annex E may be subject to a more frequent update than this main document. Therefore, the  
annex is not included. The current version (Release A or later) can be downloaded from the  
OMS website (www.oms-group.org).  
10  
E.1 Requirements for Smart Meter Gateways in Germany  
The German law requires an approval for the operation of a Smart Meter Gateway in Germany.  
This approval checks both the security and the interoperability of a Smart Meter Gateway. The  
[BSI TR03109] describes the requirement to such a Smart Meter Gateway.  
Such a Smart Meter Gateway has to reject an unsecure communication link to a smart OMS  
end-device. The Annex E.1 describes which services and security methods of the OMS-  
Specification shall be applied and which services are not allowed to conform to [BSI TR03109].  
15  
E.2 Requirements for Compliance with IDIS Association in Europe  
This section describes the functionalities and features that an OMS end-device must support  
in order to be able to communicate with an IDIS E-meter according to IDIS Pack 3.  
20  
OMS GROUP  
103/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex F (Normative):  
Transport Layer Security (TLS) with Wireless M-Bus  
The German law requires an approval for the operation of a Smart Meter Gateway in Germany.  
This approval checks both the security and the interoperability of a Smart Meter Gateway. The  
[BSI TR03109] describes the requirements to the interface of a Smart Meter Gateway.  
5
10  
15  
One requirement is the TLS-protection of connections to meters with a bidirectional  
communication interface in the Local Metrological Network (LMN). This annex describes a BSI  
conform implementation of a TLS-communication on the wireless M-Bus.  
TLS protected communication may also be used on wired M-Bus connections. However, the  
wired M-Bus interface is not a mandatory interface of a Smart Meter Gateway according to  
[BSI TR03109].  
Annex F may be subject to a more frequent update than this main document. Therefore, the  
annex is not included. The current version (Release B or later) can be downloaded from the  
OMS website (www.oms-group.org).  
OMS GROUP  
104/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex G (Normative): Conversion of a Load Profile to  
Single Data Points  
G.1 Treatment of Historical Values in Compact Load Profiles with  
Registers  
5
Sets of historical billing values, indicated by the value group F (with F<255) of an OBIS-Code  
and assigned to dedicated COSEM objects, are always coded with a final DIFE with the value  
00h. The number of DIFEs is variable. Such sets of historical billing values shall use a Compact  
Load Profiles with registers.  
The final DIFE shall be used in the DIBs of all three related data points (Base Time, Base  
Value and Compact Load Profile with registers).  
10  
NOTE: Sets of historical billing values, indicated by the value group F (with F = 255) of an  
OBIS-Code, like a Due Date Value, never use the final DIFE and apply the Compact Load  
Profile without registers.  
G.2 Applicable Standard  
15  
The Standard load profile and the Compact Load Profile shall be compatible to the description  
of [EN 13757-3:2018], Annex F.  
The orthogonal VIFE of the Compact Load Profile, as defined [EN 13757-3:2018], Annex F,  
F.2.6 to F.2.8, shall be used as last VIFE in the VIB.  
NOTE: If an MB tag from Annex B is to be used as a compact profile, set the extension bit (see  
[EN 13757-3:2018], 6.3.6) of the last VIF/VIFE and append the corresponding orthogonal  
VIFE.  
20  
G.3 Applicable Storage numbers  
For the OMS Conformance test a standard profile or a compact profile will be first converted  
to a set of single data points (see G.3 to G.6) before the compliance with Annex B is checked.  
For these single data points, the transmitted storage number and the following storage  
numbers are used. All these storage numbers shall not overlap with the storage numbers of  
other transmitted data points having a different reference time.  
25  
G.4 Data Set of the Example  
The following examples show how an original set of periodical consumption values is coded  
as Standard Load Profile or Compact Load Profile and how these Load Profiles are converted  
to a set of single M-Bus data points.  
30  
Table G.1 Example: Load profile of consumption values for a water meter  
1st value at the end of the month  
2nd value at the end of the month  
3rd value at the end of the month  
4th value at the end of the month  
Last value at the end of the month  
2008-01-31  
2008-02-29  
2008-03-31  
2008-04-30  
2008-05-31  
65 litres (10-3 m³)  
209 litres  
423 litres  
755 litres  
1013 litres  
OMS GROUP  
105/143  
           
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
G.5 Example for Standard Load Profile  
Table G.2 Example: Standard Load Profile composed of the periodical volume values  
DIB  
VIB  
Data  
Hex coded  
(LSB first)  
Data field  
Storage  
number  
89 04 FD 22 05  
2 digit BCD  
2 digit BCD  
16 bit binary  
8 digit BCD  
8 digit BCD  
8 digit BCD  
8 digit BCD  
8 digit BCD  
8
8
Size of storage block  
Storage interval in months  
Date (Type G)  
5
89 04 FD 28 01  
1
82 06 6C 1F 15  
12  
8
2008-05-31  
65  
8C 04 13 65 00 00 00  
CC 04 13 09 02 00 00  
8C 05 13 23 04 00 00  
CC 05 13 55 07 00 00  
8C 06 13 13 10 00 00  
Volume (liters)  
9
Volume (liters)  
209  
10  
11  
12  
Volume (liters)  
423  
Volume (liters)  
755  
Volume (liters)  
1013  
Table G.3 Example: Periodical volume values converted to single data points  
DIB  
VIB  
Data  
Hex coded  
(LSB first)  
Data field  
Storage  
number  
82 04 6C 1F 11  
16 bit binary  
8 digit BCD  
16 bit binary  
8 digit BCD  
16 bit binary  
8 digit BCD  
16 bit binary  
8 digit BCD  
16 bit binary  
8 digit BCD  
8
8
Date (Type G)  
Volume (liters)  
Date (Type G)  
Volume (liters)  
Date (Type G)  
Volume (liters)  
Date (Type G)  
Volume (liters)  
Date (Type G)  
Volume (liters)  
2008-01-31  
65  
8C 04 13 65 00 00 00  
C2 04 6C 1D 12  
9
2008-02-29  
209  
CC 04 13 09 02 00 00  
82 05 6C 1F 13  
9
10  
10  
11  
11  
12  
12  
2008-03-31  
423  
8C 05 13 23 04 00 00  
C2 05 6C 1E 14  
2008-04-30  
755  
CC 05 13 55 07 00 00  
82 06 6C 1F 15  
2008-05-31  
1013  
8C 06 13 13 10 00 00  
5
NOTE: Corresponding table cells in Tables G2 and G3 are marked with corresponding  
background colours.  
OMS GROUP  
106/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
G.6 Example for Compact Load Profile  
Table G.4 Example: Compact Load Profile composed of the periodical volume values  
DIB  
VIB  
Data  
Hex coded  
LSB first  
Spacing control byte  
8C 04 13 65 00 00 00  
82 04 6C 1F 11  
8 digit  
BCD  
8 Volume  
(liters)  
65  
16 bit  
binary  
8 Format  
G
2008-01-31  
8D 04 93 1F 0A 7A FE  
44 01 14 02 32 03 58  
02  
Variable 8 Volume 10 Incre- Full  
4 digit 254  
144, 214,  
332, 258  
length  
(liters)  
ments month BCD  
Table G.5 Example: Periodical volume values converted to single data points  
DIB  
VIB  
Data  
Hex coded  
(LSB first)  
Data field  
Storage  
number  
82 04 6C 1F 11  
16 bit binary  
16 bit binary  
16 bit binary  
16 bit binary  
16 bit binary  
8 digit BCD  
8 digit BCD  
8 digit BCD  
8 digit BCD  
8 digit BCD  
8
9
Format G  
2008-01-31  
2008-02-29  
2008-03-31  
2008-04-30  
2008-05-31  
65  
C2 04 6C 1D 12  
Format G  
82 05 6C 1F 13  
10  
11  
12  
8
Format G  
C2 05 6C 1E 14  
Format G  
82 06 6C 1F 15  
Format G  
8C 04 13 65 00 00 00  
CC 04 13 09 02 00 00  
8C 05 13 23 04 00 00  
CC 05 13 55 07 00 00  
8C 06 13 13 10 00 00  
Volume (liters)  
Volume (liters)  
Volume (liters)  
Volume (liters)  
Volume (liters)  
9
209  
10  
11  
12  
423  
755  
1013  
5
NOTE: Corresponding table cells in Tables G4 and G5 are marked with corresponding  
background colours.  
OMS GROUP  
107/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
G.7 Example for an Inverse Compact Load Profile  
Table G.6 Example: Inverse Compact Load Profile composed of the periodical volume values  
DIB  
VIB  
Data  
Hex coded  
LSB first  
Spacing control byte  
8C 04 13 13 10 00 00  
82 04 6C 1F 15  
8 digit  
BCD  
8 Volume  
(liters)  
1013  
16 bit  
binary  
8 Format  
G
2008-05-31  
8D 04 93 13 0A 7A FE  
58 02 32 03 14 02 44  
01  
Variable 8 Volume 10 Incre- Full  
4 digit 254  
258, 332,  
214, 144,  
length  
(liters)  
ments month BCD  
Table G.7 Example: Periodical volume values converted to single data points  
DIB  
VIB  
Data  
Hex coded  
(LSB first)  
Data field  
Storage  
number  
82 04 6C 1F 11  
16 bit binary  
16 bit binary  
16 bit binary  
16 bit binary  
16 bit binary  
8 digit BCD  
8 digit BCD  
8 digit BCD  
8 digit BCD  
8 digit BCD  
12  
11  
10  
9
Format G  
2008-01-31  
2008-02-29  
2008-03-31  
2008-04-30  
2008-05-31  
65  
C2 04 6C 1D 12  
Format G  
82 05 6C 1F 13  
Format G  
C2 05 6C 1E 14  
Format G  
82 06 6C 1F 15  
8
Format G  
8C 04 13 65 00 00 00  
CC 04 13 09 02 00 00  
8C 05 13 23 04 00 00  
CC 05 13 55 07 00 00  
8C 06 13 13 10 00 00  
12  
11  
10  
9
Volume (liters)  
Volume (liters)  
Volume (liters)  
Volume (liters)  
Volume (liters)  
209  
423  
755  
8
1013  
5
NOTE: Corresponding table cells in Table G.6 and Table G.7 are marked with corresponding  
background colours.  
OMS GROUP  
108/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex H (Informative):  
Gas Meter Consumption Data and Their Coding  
H.1 Glossary  
Table H.1 Glossary of the Gas meter consumption data  
Vm  
The volume at measurement conditions  
Temperature converted volume  
The volume at base conditions  
Vtc  
Vb  
Measurement conditions  
Conditions of the gas whose volume is measured  
at the point of measurement (e.g. the temperature  
and the pressure of the gas)  
[EN 12405]  
Base conditions  
Fixed conditions used to express the volume of  
gas independently of the measurement conditions  
[EN 12405]  
Converted volume  
The converted volume from the quantity  
measured at measurement conditions into a  
quantity at base conditions  
5
H.2 Overview  
For billing purposes, the measured volume of a gas meter needs to be converted into energy.  
Depending on the technology of the gas meter there might be several parameters for this  
conversion:  
Temperature  
Pressure  
Gas calorific value  
10  
The conversion from the volume at measurement conditions (Vm) to the volume at base  
conditions (Vb) can be done by the gas meter, by a conversion device, and/or by the billing  
system. Gas meters with built in temperature conversion device convert Vm to Vtc.  
15  
20  
In general, the mentioned conversions can be done explicitly using devices measuring, the  
specific condition, or also implicitly by meters that measure independently from the specific  
condition.  
To inform the billing centre on possible conversions already done by the meter or a conversion  
device, the consumption data transmitted shall include a clear indication on both, the  
conversion types and the base conditions to which the conversion is done. For meters with  
integrated or external conversion directly to energy, the energy-oriented VIFs (e.g. “kWh”) to-  
gether with the Device Type “gas” = 03h will provide such a clear indication, which does not  
require further information.  
OMS GROUP  
109/143  
       
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
H.3 Volume at Measurement Conditions  
All conversions are done solely at the billing centre, by assumption of measurement conditions  
that could not be measured, typically using legally defined gas temperatures and typical gas  
installations and/or installation height to take the pressure into account.  
Vm  
Gas meter  
5
Figure H.1 Gas meter providing volume at measurement conditions  
Note that the same coding is used for the raw, uncorrected original value if the meter internally  
corrects its volume accumulation for possible flow dependent errors, since this will not  
influence the billing process.  
Suitable OBIS and M-Bus codes can be found in Annex A.  
10  
15  
H.4 Temperature Converted Volume Vtc  
An individual meter based volume conversion to Vtc (in contrast to the “global” billing centre  
based conversion) can be achieved either mechanically or electronically. It can be implemen-  
ted either internally in the meter or by some external conversion device, which then transmits  
converted values to the billing centre. Note that such a temperature conversion is based on a  
base temperature, which must be known to the billing centre. The default value for such a  
temperature at base conditions is 15 °C according to the [EN 1359].  
If a meter uses a different base temperature, its temperature at base conditions information  
shall be transmitted with each volume data message.  
Note that meter data can be converted by the billing centre to its “billing temperature at base  
conditions”, if this is different either from the default temperature of 15 °C or from the meters  
transmitted temperature at base conditions.  
20  
Vtc  
T
Gas meter  
Figure H.2 Gas meter providing temperature converted volume  
Suitable OBIS and M-Bus codes can be found in Annex AAnnex A.  
OMS GROUP  
110/143  
       
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
H.5 Temperature and Pressure Converted Volume  
In addition to a volume conversion just regarding temperature, an individual meter might  
convert its measured volume to base conditions regarding temperature and pressure. To  
comply with standard conditions, which are usually stated by national regulations and to allow  
the creation of gas bills that can easily be understood by the consumer, the same temperature  
at base conditions shall be used as for the calorific value in the case when both temperature  
and pressure are converted.  
5
10  
15  
Devices complying with this do not need to send the information of the temperature at base  
conditions.  
Note that a purely pressure converted volume, without temperature, is not supported.  
Such a volume conversion is based on a pressure at base conditions, which must be known  
to the billing centre. The default value for such a pressure at base conditions is 1013,25 mbar.  
If a meter uses a different value for pressure at base conditions, such pressure at base  
conditions information shall be added to each volume data message.  
Note that meter data can be converted at the billing centre to its “billing pressure at base  
conditions”, if this is different either from the default pressure of 1013,25 mbar or from the  
meter’s transmitted pressure at base conditions.  
Vb  
temperature and  
preasure  
converted  
p T  
Vm  
Gas meter  
Figure H.3 Gas meter providing temperature and pressure converted volume  
Suitable OBIS and M-Bus codes can be found in Annex A and Annex B.  
OMS GROUP  
111/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
H.6 OBIS / COSEM Application of Physical Units for Gas  
(Extract from [DLMS UA] Blue Book ed. 13)  
Table H. shows available physical units for the gas data objects given above. By application  
of a scale factor (ref. Table H3) the values can be scaled as required.  
5
Table H.2 Enumerated values for physical units  
Unit  
::=  
Unit  
Quantity  
Unit name  
SI definition  
(comment)  
enum  
(9)  
°C  
m3  
temperature (T)  
degree-Celsius K 273,15  
(13)  
volume (V)  
cubic meter  
m3  
rV , meter constant or pulse value (volume)  
(14)  
(19)  
(23)  
(24)  
(52)  
m3  
l
Converted volume  
Volume  
cubic meter  
litre  
m3  
10-3 m3  
N/m2  
Pa  
bar  
K
pressure (p)  
pressure (p)  
temperature (T)  
pascal  
bar  
105 N/m2  
kelvin  
Some examples are shown in Table H.3 below.  
Table H.3 Examples for scaler-unit  
Value  
263788  
593  
Scaler  
Unit  
m3  
Data  
-3  
3
263,788 m3  
593 kWh  
3467 V  
Wh  
V
3467  
0
OMS GROUP  
112/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex I (Normative):  
Collision Avoiding Mechanism of the Gateway  
The following describes a mechanism for automatic retransmissions from interrogating devices  
in order to resolve collisions on the radio channel. The algorithm is based on a maximum  
number of N retries (with N = 11) and choosing a random listen-after-talk-timeslot of the  
addressed OMS end-device. Furthermore, it evaluates the received message types to prevent  
disturbing other conversations.  
5
OMS GROUP  
113/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
I.1 Flowchart  
Start  
Transmit  
datagram to  
target-OMS end-  
device  
(optional)  
End:  
Communication  
failed  
n = 1  
yes  
N: Maximum  
Number of retries  
yes  
n > 2?  
no  
n > N ?  
no  
T = Random  
T = 1  
T is equally distributed  
between 1 and 2  
n = n + 1  
t = 1  
yes  
Wait until  
n < 2  
or  
t > 2?  
datagram from  
target OMS end-  
device received  
no  
no  
End:  
Communication  
OK  
Timeout?  
no  
no  
yes  
Further  
datagram  
pending?  
t = t + 1  
Addresse of  
ACK or RSP ?  
ACK or RSP-  
UD received?  
yes  
yes  
no  
no  
t = T ?  
yes  
yes  
Re-init algorithm  
n =1  
Transmit  
datagram to target  
OMS end-device  
t = 1  
(T = 1)  
Figure I.1 - Collision avoiding algorithm  
OMS GROUP  
114/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
I.2 Explanation  
Figure I.1 shows the procedure to transmit a message to a bidirectional OMS end-device  
including the retry-mechanism. The parameter N gives the maximum number of retries.  
The retry-algorithm applies three variables:  
5
n
t
Counts the number of tries to send the datagram  
Counts the number of datagrams received during the actual try  
Determines the datagram that will be followed by a transmission  
T
In case of two unsuccessful tries resulting in n larger than 2, T is randomly chosen to 1 or 2  
with a uniform distribution at the start of every (re-)try.  
10  
The basic idea is that within every try the interrogating device uses only one of two  
opportunities to transmit. This means that for both the first and second try the very first  
opportunity is used and for all following tries it would be either the first or the second one. The  
unused opportunity reduces the collision probability for competing devices and therefore  
contributes to a recovery of the overall-system.  
15  
20  
A transmission to the addressed module is only performed under certain conditions. Of course,  
the general condition is the reception of a datagram from the target OMS end-device to meet  
the following listen-after-talk window. The algorithm evaluates furthermore, if the datagram is  
related to an already ongoing conversation, which is the case if the datagram is an  
acknowledgment or a response. In this case, it is further evaluated if this datagram is  
addressed to the interrogating device trying to send a transmission. If not, the device keeps on  
listening in order to leave this other conversation undisturbed. In case the ACK or RSP is  
dedicated to the device, the previous transmission is considered as successfully transmitted7.  
If the received datagram is neither part of another conversation nor the confirmation that a  
previous datagram was received, this would be an opportunity to send the datagram in case  
t equals T. Again, this latter additional condition resolves collision-scenarios with several  
devices transmitting simultaneously.  
25  
I.3 Example: Access of One Gateway without Collision  
Assume a scenario with only one gateway addressing an OMS end-device with a sufficient  
radio propagation in-between. The algorithm is initialized with n = 1, t = 1 and T = 1. As a  
consequence, the very first received datagram from the target OMS end-device is followed by  
the gateways transmission. An ACK by the OMS end-device, which should be received in a  
collision-free environment, confirms the reception and results in the transmission of the next  
datagram by the gateway. Therefore, compared to a system without the retry-mechanism, the  
performance in terms of latency or throughput is not influenced in any way.  
30  
35  
Figure I.2 shows this behaviour versus time together with the three variables of the algorithm.  
7
Based on the assumption, that the access-counter of the response can be used to match the answer  
of the interrogated module to the query.  
OMS GROUP  
115/143  
     
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
RF-Connection with Command  
GW  
(LLA=GW1)  
OMS end-device  
(LLA=ALA=OED)  
n
t
T
1
GW has new CMD.  
Algorithm is  
initialized.  
1
1
Message is received  
during a short  
reception windows  
followed after every  
transmission (when  
bit B=1 and A=0)  
After OMS end-  
device transmitts and  
t = T, GW sends  
Command.  
An Acknowledge is  
responded with  
predefined delay.  
GW receive  
Acknowledge and  
finish communikation.  
Because this is a  
new telegram, the  
algorithm is re-  
initialized.  
1
1
1
OMS end-device  
receive  End of  
Transmission  and  
stops retransmission.  
Figure I.2 Timing diagram without collisions  
I.4 Example: Access of Two Gateways with Collision  
Assume a scenario with two gateways and an OMS end-device, again with sufficient and equal  
radio propagation between the gateways and the OMS end-device. Due to some reason, on  
both gateways a command appears to be sent to the OMS end-device. Note that it cannot be  
sent immediately in case the OMS end-device's receiver is not always on. Therefore, this  
scenario applies even in case of minutes between the appearances of the commands if the  
addressed OMS end-device has not transmitted since then, meaning that there was no  
opportunity to transmit the command.  
5
10  
15  
Both gateways initialize the algorithm in the same way. In our assumption the received field  
strength of both gateways is equal at the OMS end-device and therefore the transmissions are  
jammed. Because the OMS end-device cannot receive any command in this case, there will  
not be an ACK by the module. Therefore, the number of received datagrams during this first  
try is increased to 2. This furthermore results in starting the next try by increasing n from 1 to  
2. Also, for the second try, T is set to 1 (see Figure I.1) and therefore the very next opportunity  
is used, which again ends up in a collision. For the next try with n = 3, the random generator  
of every gateway determines T which now can be 1 or 2. Assuming a uniform distribution, there  
is a 50 % probability that two gateways choose different timeslots. This scenario is sketched  
in the following chart.  
OMS GROUP  
116/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
RF-Connection with Command  
GW1  
(LLA=GW1)  
OMS end-device  
(LLA=ALA=OED)  
GW2  
(LLA=GW2)  
n
t
T
1
n
t
T
1
GW1 has new CMD.  
Algorithm is  
initialized.  
GW2 has new CMD.  
Algorithm is  
initialized.  
1
1
1
1
After OMS end-  
device transmitts and  
t = T, GW1 sends  
Command.  
After OMS end-  
device transmitts and  
t = T, GW2 sends  
Command.  
Collision, OMS end-  
device does not  
receive any CMD,  
therefore, it does not  
ACK  
2
1
1
2
1
1
GW1 starts 2nd try.  
GW2 starts 2nd try.  
After OMS end-device  
transmitts and t = T,  
GW1 sends Command.  
After OMS end-  
device transmitts and  
t = T, GW2 sends  
Command.  
Collision, OMS end-  
device does not  
receive any CMD,  
therefore, it does not  
ACK  
3
1
1
3
1
2
GW1 starts 3rd try.  
Random generator picks  
1st opportunity (T = 1).  
GW2 starts 3rd try.  
Random generator picks  
2nd opportunity (T = 2).  
After OMS end-device  
transmitts and t = T,  
GW1 sends Command.  
Although OMS end-device  
transmits, GW2 does not  
send command because t  
  T. Afterwards, t is in  
creased  
3
3
2
2
2
2
1
1
1
GW1 receives  
acknowledge and  
finishes communikation.  
Because this is a new  
telegram, the algorithm  
is re-initialized.  
Although OMS end-device  
transmits and t = T, GW2  
does not send command  
because ACK use a  
wrong ACC-Number.  
3
3
2
2
2
2
After OMS end-device  
transmits again and t = T,  
GW2 sends Command.  
GW2 receives  
acknowledge and finishes  
communikation. Because  
this is a new telegram, the  
algorithm is re-initialized.  
1
1
1
Figure I.3 Timing diagram with collisions  
After the collision of the gatewaysfirst two transmissions, both start a 3rd try with GW1  
choosing the 1st and GW2 the 2nd opportunity. As a result, GW1 transmits the command after  
the next received datagram, whereas GW2 waits for the next possibility. Because the following  
transmissions of the OMS end-device are dedicated to GW1, GW2 does not take these  
opportunities, although t is equivalent to T. Note that the received datagrams dedicated to  
another conversation do not result in incrementing t (see Figure I.1). After this conversation  
with GW1 is finished, GW2 takes the next datagram originating from the OMS end-device to  
transmit its pending datagram.  
5
OMS GROUP  
117/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
I.5 Collision Probabilities  
If more than one interrogating device wants to send a command at the same time, this results  
always in a collision during the first two tries. If there are two devices, the probability to get a  
collision during the nth try with n larger than 2 is 0,5² × 2 = 0,5.  
5
0,5² is the probability that both devices choose the same opportunity and the multiplier 2 is  
reasoned by two possible opportunities. In general, the probability for collision is 1 in case of  
the first and second try and 0,5 for every other retries in case of two competing devices.  
With the number of tries, the probability decreases that further tries are necessary. For  
example, the probability to have at least 3 tries is 1 and is the consequence of the 100 %  
collision probability for the 1st and 2nd try. The probability to have at least 4 tries is 1 × 1 × 0,5  
and therefore the result of having a collision in the 1st, 2nd and 3rd try. In general, the probability  
to have the necessity for at least n tries is 1 × 0,5n-2 (for n > 2).  
10  
Retries for two devices  
1
0.9  
0.8  
0.7  
0.6  
0.5  
Probability of (re-)tries  
0.4  
0.3  
0.2  
0.1  
0
1
2
3
4
5
6
7
8
9
10  
11  
12  
13  
14  
15  
Number of tries  
Figure I.4 Collision probability  
The probability for 12 tries or more is about 0,2 %, therefore a maximum number of N = 11  
would be a suitable limit for the proposed algorithm. This limits the number of opportunities to  
a maximum of 1 + 1 + 9 × 2 = 20.  
15  
OMS GROUP  
118/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex J (Informative): Handling of Message Counter  
OMS GROUP  
119/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
OMS GROUP  
120/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
OMS GROUP  
121/143  
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Figure J.1 Example of message counter handling  
OMS GROUP  
122/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex K (Normative): Descriptors  
K.1 General  
The purpose of a descriptor is the declaration of the meaning of DIB-elements in the individual  
device. Following DIB-elements of data points can be declared by descriptors.  
5
Table K.1 Overview of descriptors and related DIB-elements  
DIB-element  
Storage number  
Tariff  
Descriptor  
Storage interval descriptor  
Tariff descriptor  
Subunit  
Subunit descriptor  
The link between the descriptor and the data point(s) is always the DIB-element. The DIB-  
element of a data point is identical to the DIB-element of the descriptor (see Table K.1). The  
values of the other DIB elements do not matter. For example, the subunit descriptor with a  
subunit of 1 is applicable for all data points with the same subunit regardless of its value of the  
DIB-elements storage number, tariff, or function.  
10  
A descriptor is valid for all DIB-elements in the device; e.g. the declaration of tariff number 1  
shall be applied to all storage numbers and subunits.  
A descriptor shall not change its definition over the lifetime of an OMS end-device. A new  
descriptor may be added for new data points during the lifetime of an OMS end-device. An  
existing descriptor may be deleted if the referenced data point is not used anymore.  
15  
K.2 Storage Descriptors  
K.2.1 Storage Interval Descriptor  
K.2.1.1 Usage  
The storage interval descriptor declares the usage of a single storage number or a range of  
storage numbers for historical values. Historical values are one or several measurement  
values that have been generated in the past. Typically, historical values are generated  
periodically at a pre-set date and time like each full hour or at the end of a month. The OMS  
end-device may transmit either a single historical value (e.g. the value at the end of last month)  
or a set of historical values (e.g. the last 24-hourly values).  
20  
25  
A single historical value is mostly transmitted together with a time stamp, which is linked with  
the historical value by the same storage number.  
A set of historical data is transmitted either with a time stamp for each historical value or as a  
pure set of historical values with only a start date/time and an interval (refer to standard profile  
in [EN 13757-3:2018], Annex F.1).  
30  
The storage interval descriptor is used to declare the temporal relation between the values. In  
a set of historical values, it describes the applied interval between the values (e.g. one hour).  
In a single data point it declares the time when the next single historical value is expected (e.g.  
next new value of this storage number will be generated during a month).  
OMS GROUP  
123/143  
       
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
K.2.1.2 Coding  
The temporal relation shall be declared according to Table K.2.  
Table K.2 Declaration of Storage interval descriptors  
M-Bus data point  
VIB  
Description  
Year  
Storage interval year(s)  
FDh 29h  
FDh 28h  
FDh 27h  
FDh 26h  
FDh 25h  
FDh 24h  
Storage interval month(s)  
Month  
Day  
Storage interval [sec(s) … day(s)]  
Storage interval [sec(s) … day(s)]  
Storage interval [sec(s) … day(s)]  
Storage interval [sec(s) … day(s)]  
Hour  
Minute  
Second  
The value of the data point storage interval descriptor is coded as type B (according to  
[EN 13757-3:2018], Annex A). The value equals the used storage interval and is frequently 1.  
A storage interval of 0 describes that all values refers to the same point in time or that these  
values have no temporal relation.  
5
10  
15  
In case of a single historical value, the storage interval descriptor uses the storage number of  
the data point.  
In case of a standard profile, the storage interval descriptor uses the storage number of the  
oldest measurement value in the set of historical values.  
In case of a compact profile, the storage interval descriptor uses the storage number of base  
time respectively base value.  
The other DIB-elements tariff, function and subunit in the data point storage interval descriptor  
shall always be set to 0.  
K.2.1.3 Scope of Application  
The storage interval descriptor is mandatory for all historical values, except for  
All MB-Tags listed in Annex A,  
Historical values providing a time stamp for each used storage number,  
Storage numbers using a final DIFE (assignment is done by register-ID),  
Transmissions with compact profile according to Annex G (Note that any compact  
profile can be converted to a set of historical values with timestamps).  
20  
25  
Storage number 0 (without final DIFE) is exclusively being used for current values and values  
without a temporal relation, e.g. the fabrication number. It is not permitted to use the storage  
interval descriptor for storage number 0.  
Storage number 1 (without final DIFE) is being used for due date values. As long as the due  
date is provided no storage interval descriptor is required.  
K.2.2 Storage Range Descriptor  
Table K.3 Declaration of Storage range descriptors  
M-Bus data point  
VIB  
Description  
First storage number for cyclic storage  
Last storage number for cyclic storage  
Size of storage block  
FDh 20h  
FDh 21h  
FDh 22h  
Time point for start of range (oldest value)  
Time point for end of range (newest value)  
Number of applied storage numbers  
30  
The storage range descriptor FDh 21h uses the storage number of the newest value in the  
load profile. The storage range descriptors FDh 20h and FDh 22h use the storage number of  
the oldest value in the load profile. The data point sub fields for tariff, function, and subunit in  
the data point storage range descriptor shall be set to 0. The storage range descriptors FDh  
20h and FDh 21h do not transmit values.  
OMS GROUP  
124/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
The transmission of a storage range descriptors is generally optional, with a few exceptions.  
Under the following conditions the use of the storage range descriptor is mandatory:  
1. If several sets of historical values with more than one pair of values are transmitted,  
a storage range descriptor according to Table K.3 shall be included in the message.  
All sets in this message shall use the same type of storage range descriptor.  
2. If the storage number of the oldest value in a set of historical values is not the  
smallest storage number in this set, then this storage number shall be declared with  
the storage range descriptor FDh 20h.  
5
K.3 Subunit Descriptor  
10  
The subunit descriptor declares the usage of the subunit number.  
The subunit descriptor is coded with 01h FDh 23h xx. The values for xx are listed in Table K.4.  
NOTE: The VIB of the subunit descriptor is the same as for the tariff descriptor.  
Table K.4 Subunit index values for the subunit descriptor  
Index value Description  
Media type  
Comment  
0
Main register, legacy  
all  
1
OBIS value group B = 1  
OBIS value group B = 2  
OBIS value group B = 3  
OBIS value group B = 4  
Tariff subunit  
electricity meter  
2
electricity meter  
3
electricity meter  
4
electricity meter  
5
all  
all  
all  
all  
all  
all  
all  
all  
all  
all  
6
Minimum subunit  
7
Maximum subunit  
Data logger  
8
9
Event logger  
e.g. error logging  
Test results  
10  
Test subunit/test mode  
Calibration subunit  
Adjustment subunit  
Pulse collector 1…8  
11  
Calibration results  
Adjustment values  
12  
13..20  
21…29  
Configuration subunit/configuration  
mode  
30…99  
Reserved  
100…127  
128…255  
Manufacturer specific  
Reserved for other descriptors  
all  
It is not permitted to use the subunit descriptor for the subunit value 0. The transmission of the  
subunit descriptors is mandatory for all subunit values greater than 0. For the case of a Subunit  
index value of 0 the transmission of the subunit descriptors may be omitted.  
15  
The subunit descriptor shall use the subunit number of the declared subunit. The DIB-elements  
storage number, function and tariff in the data point 'subunit descriptor' shall be set to 0.  
OMS GROUP  
125/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
K.4 Tariff Descriptor  
The tariff descriptor declares the usage of the tariff register number.  
The tariff descriptor is coded with 01h FDh 23h xx. The values for xx are listed in Table K.5.  
NOTE: The VIB of the tariff descriptor is the same as for the subunit descriptor.  
Table K.5 Tariff index values for the tariff descriptor  
5
Index value Description  
Device type  
Comment  
0…127  
Reserved for other descriptors  
General tariffs  
Manufacturer specific  
128…139  
140…149  
Reserved  
Time based tariffs  
Absolute time of day  
150  
151  
All  
All  
All  
e.g. 8:00 to 11:00  
each day  
Weekdays  
e.g. each Saturday  
and Sunday  
e.g. each 15th.  
152  
Days in Month  
Reserved  
153…159  
Threshold based tariffs  
160  
161  
162  
163  
Difference temperature  
Forward temperature  
Return temperature  
Heat, Cold  
Heat, Cold,  
Heat, Cold  
Heat, Cold  
a
Return temperature threshold for  
calculation of theoretical energy  
164  
Volume Flow  
Water, Heat, Cold,  
Gas  
165  
Power  
Electricity, Heat, Cold  
166…189  
Reserved  
Consumption based tariffs  
Energy consumption  
190  
191  
Electricity, Heat, Cold e.g. after consumption  
of 100 kWh  
Volume consumption  
Water, Heat, Cold,  
Gas  
192  
Financial consumption  
Reserved  
All  
e.g. prepaid tariffs  
193…209  
Combined tariffs  
210  
Time and threshold based  
Time and consumption based  
Threshold and consumption based  
Reserved  
211  
212  
213…229  
OMS GROUP  
126/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Table K.5 (continued)  
Index value Description  
Device type  
Comment  
Other tariffs  
Energy positive  
230  
231  
232  
233  
234  
Electricity, Heat, Cold  
Electricity, Heat, Cold  
Heat, Cold,  
Energy negative  
Energy heating  
Energy cooling  
External input 1  
Heat, Cold,  
All  
Controlled by user  
from outside  
235  
External input 2  
All  
Reserved  
236…249  
Reserved  
250…255  
Reserved for table extension  
a
The energy is accumulated in tariff registers depending on the return (outlet) temperature. The  
quantity of this energy results from a mathematical calculation is based on the difference of return  
(outlet) temperature and a pre-defined return temperature threshold. It can be distinguished  
between accumulated energy in case the return temperature is lower or higher than the return  
threshold value. This can be signaled with the orthogonal VIFE 40h or 48h.  
It is not permitted to use the tariff descriptor for the tariff value 0. The transmission of tariff  
descriptors is mandatory for all tariff values greater than 0, except for the following conditions:  
A combined heat/cooling meter uses the tariff register 1 for the cooling energy.  
All MB-Tags listed in Annex A  
5
The tariff descriptor shall use the tariff register number of the declared tariff. The DIB-elements  
storage number, function and subunit in the data point 'tariff descriptor' shall be set to 0.  
K.5 Examples  
K.5.1 Example: Storage Descriptor  
10  
Table K.6 Example load profile for storage descriptor  
1st value at the end of the month  
2nd value at the end of the month  
3rd value at the end of the month  
4th value at the end of the month  
Last value at the end of the month  
2008-01-31  
2008-02-29  
2008-03-31  
2008-04-30  
2008-05-31  
65 litres (10-3 m³)  
209 litres  
423 litres  
755 litres  
1013 litres  
OMS GROUP  
127/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Table K.7 Example for coding of the storage descriptor  
DIB  
VIB  
Data  
Hex coded  
(LSByte first)  
Data field  
Storage  
number  
89 04 FD 22 05  
2 digit BCD  
2 digit BCD  
16 bit binary  
8 digit BCD  
8 digit BCD  
8 digit BCD  
8 digit BCD  
8 digit BCD  
0 bit  
8
8
Size of storage block  
Storage Interval Descriptor months  
Date (Type G)  
5
89 04 FD 28 01  
1
82 06 6C 1F 15  
12  
8
2008-05-31  
8C 04 13 65 00 00 00  
CC 04 13 09 02 00 00  
8C 05 13 23 04 00 00  
CC 05 13 55 07 00 00  
8C 06 13 13 10 00 00  
80 06 FD 21  
Volume (litres)  
65  
9
Volume (litres)  
209  
423  
755  
1013  
-
10  
11  
12  
12  
Volume (litres)  
Volume (litres)  
Volume (litres)  
Storage Range Descriptor “End”  
K.5.2 Example: Subunit Descriptor  
The following definition links subunit 2 to a data logger: 81h 80h 40h FDh 23h 08h  
K.5.3 Example: Tariff Descriptor  
5
The following definition links tariff 3 to the threshold based tariff “Difference Temperature”: 81h  
30h FDh 23h A0h  
OMS GROUP  
128/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex L (Informative): Timing Diagram  
The next pages show examples of Timing diagrams for Mode C. If the Access Number is not  
explicitly declared, then the shown Access number is the Access Number of the ELL or of the  
TPL (if the ELL does not exist).  
5
L.1 Legend  
OMS GROUP  
129/143  
   
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
L.2 Unidirectional OMS end-device with Synchronous and  
Asynchronous Transmission  
OMS GROUP  
130/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
L.3 RF-Connection with SND-UD and Short TPL  
OMS GROUP  
131/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
L.4 Transmission of Fragmented Message with SND-UD  
OMS GROUP  
132/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
L.5 Transmission of ACK + RSP-UD with Different Command States  
OMS GROUP  
133/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
L.6 RF-Connection with SND-UD2 and Long TPL  
OMS GROUP  
134/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
L.7 Connection Timeout of the Frequent Access Cycle  
OMS GROUP  
135/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
L.8 Access Demand from OMS end-device  
OMS GROUP  
136/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
L.9 Installation Procedure  
OMS GROUP  
137/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex M (Normative): Requirements for OMS Use Case  
Support  
This annex contains specifications of interoperable OMS use cases of OMS end-devices. The  
set of optional use cases support for example clock management, disconnect/reconnect, key  
management, firmware update etc.  
5
The annex in addition contains general introduction to basic communication sequences for  
both wired and wireless M-Bus to support these use cases.  
The OMS end-device support for specific use cases is declared by the manufacturer in the  
[ManDec].  
10  
This annex may be subject to a more frequent update than this main document. Therefore, the  
annex is not included. The current version (Release C or later) can be downloaded from the  
OMS website (www.oms-group.org).  
OMS GROUP  
138/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex N (Informative):  
Datagram Examples for Wired M-Bus and Wireless M-Bus  
This annex lists several message examples for wired and wireless M-Bus. Be aware that this  
is an informative annex. In case of deviation between this annex and the normative  
specification, the content of specification has to be applied.  
5
For the sake of better readability this annex is not included.  
The current version (Release E or later) can be downloaded from the OMS website (www.oms-  
group.org).  
OMS GROUP  
139/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex O (Informative):  
Alternative Physical Layers for OMS  
Countries outside the CEPT may have defined other frequencies than those covered in the  
OMS-PC. OMS gives a recommendation on the usage of alternative Physical Layers and the  
country specific parameters.  
5
Annex O may be subject to a more frequent change than this main document. Therefore, the  
annex is not included. The current version (Release B or later) can be downloaded from the  
OMS website (www.oms-group.org).  
OMS GROUP  
140/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex P (Normative and Informative): Requirements for  
Wired M-Bus  
Annex P describes the Open Metering System requirements for the wired M-Bus. The wired  
M-Bus is normatively represented in the [EN 13757-2], [EN 13757-3] and [EN 13757-7]  
standard. During application of the EN 13757 standard, a certain amount of scope for  
interpretation or design freedom is offered. Among other things, this factor applies to the coding  
of the data within the application layer.  
5
This annex may be subject to a more frequent update than this main document. Therefore, the  
annex is not included. The current version (Release C or later) can be downloaded from the  
OMS website (www.oms-group.org).  
10  
OMS GROUP  
141/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex Q (Normative): OMS LPWAN  
This annex provides all definitions for the wireless M-Bus mode OMS LPWAN.  
This annex may be subject to a more frequent update than this main document. Therefore, the  
annex is not included. The current version (Release A or later) can be downloaded from the  
OMS website (www.oms-group.org).  
5
OMS GROUP  
142/143  
 
Open Metering System Specification Vol.2 Primary Communication  
Issue 5.0.1 / 2023-12 (RELEASE)  
Annex R (Normative): Meter Reading Transmission via M-  
Bus Compact Profile; to meet BSI TR-03109-1 TAF7  
This annex provides the definitions for the OMS specific meter reading transmission for BSI  
TAF7. This implementation is in line with [BSI TR-03109-1] version 1.1.  
5
This annex may be subject to a more frequent update than this main document. Therefore, the  
annex is not included. The current version (Release A or later) can be downloaded from the  
OMS website (www.oms-group.org).  
OMS GROUP  
143/143